Share
Explore

March 2024 TO3 STATUS REPORT


Task Order 3 Overview: Task Order 3 encompasses five distinct value streams:
· Zero Trust
· Enterprise API / SONAR
· SDL (Security Data Lake)
· GRC (Governance Risk & Compliance)
· Mission Enablement
· Enterprise Cost and Scale (Aolytix)
This comprehensive project aims to modernize, secure, and facilitate various facets of CMS and its affiliate applications through its four value streams, promoting efficiency, security, and integration.

Zero Trust

Our Zero Trust initiative, batCave Zero Trust, is tailored to streamline creating and deploying a robust Zero Trust Architecture. Our vision is to mold batCave Zero Trust’s security measures into an intuitive and straightforward system for all application teams to adopt.

Key Objectives/Milestones

3.5.1: Decision Records - Completed architect decision records (ADR) for ZTA, zero trust tooling, and MFA hardware devices with consideration on how it will play within the larger enterprise.
3.5.2: Access Management Integration - Integrate the ZTA with existing CMS SOO/Identity and Access Management tools (IAM) (Okta or Azure Active Directory).
3.5.3: Tool Integration - Integrate zero trust and MFA with all batCAVE tooling to include, but not limited to logging, monitoring, support, pipeline tools, and gitlab.
3.5.4: Documentation - Write documentation and user guides for setting up the batCAVE/CMS accounts to leverage zero trust and MFA.
3.5.5: Control Mapping - Manage control mapping for the ZTA, ZT, and MFA to achieve future Authority to Operate (ATO).

Status Summary

Privilege access management is on track, finished onboarding and wrapping up testing in dev. Yubikey Pilot phase 1 is completed and materials are being shared with the GSA FIDO2 Community of Action group. IRSA gap analysis is complete and the visualization testing is underway.

Highlights

3.5.2: Access Management Integration
Privilege Access Management (PAM):
Established communication plan and support operations. Completed Phase 1 (onboarding) and Phase 2 (test in Dev), rollout using Kion IAM roles to secure internal privilege risks. Identified several configuration challenges in Phase 2. Collected metrics for new role adoption. Identified opportunities for new roles to: (1) Create a new secure workflow for k8's executive pod management; (2) Enable an ADO feature allowing Dev Access to ADO internal environments; and (3) Explore using new roles + pathways to offer a workflow with AWS secrets manager to support ADO and batCAVE secure secrets’ management.
Enable IAM Roles for Service Accounts (IRSA)
Finished gap analysis to identify the current state of IRSA implementation in batCAVE, to avoid misconfigurations and audit risks. Enhanced IRSA functionality by successfully developing and testing the ability within Local Aolytix to establish a known state configuration. This will enable retroactive compliance checks by comparing against known and documented baseline configurations for bC and ADO applications.
3.5.3: Tool Integration
Yubikey Pilot (YK):
Completed Phase 1 batCAVE pilot for CMS Zero Trust Working Group, providing the test bed for wider CMS role out. Completed testing for new EUA jobcodes for IDM TEST, IMPL, and PROD environments.
3.5.4: Documentation
Yubikey Pilot (YK):
Created YubiKey Pilot Guide and presentation slides to provide to GSA FIDO2 Communitiy of Action group.
3.5.5: Control Mapping
ARS Security Controls:
Ongoing review of control families. Working with members of CMS ZT to ensure accuracy on all the control families cross-mapping to ZT security functions. Once this work is complete we should have a vetted and comprehensive mapping that we can use to 1) bolster batCAVE ZT maturity metrics, and 2) will allow CMS to include ZT language in future ARS iterations and design practical ZT implementation guidelines for ADOs.

Lowlights

Watchtower support: On-call support of security event - discovery of API key(s) committed to an ADO repo
IRSA: No documented process or CONOPS for IRSA in batCAVE which could lead to misconfigurations and audit risks.

Dependencies

Just in Time access work under PAM: Blocked by Kion personnel changes.
YK: Phase 2 of pilot on hold until hardware is shipped by CMS Zero Trust

Risks

Just in Time access work under PAM: Blocked by Kion personnel changes.

Upcoming iterations and waves Focus

PAM: Policy tuning and enforcement, Phase 3 (Prod)
Potentially contribute Yubikey write up for
IRSA: validation, ADO baseline establishment, use case refinement
ARS: Continue to complete batCAVE specific crosswalk

Enterprise API/Sonar

Our Enterprise API application, SONAR is devoted to developing APIs, microservices, and data processing components. Its primary aim is to seamlessly integrate a myriad of CMS applications, including but not limited to batCAVE and apps deployed via batCAVE. The goal is to reduce any development or administrative hurdles.

Key Objectives/Milestones

3.2.1 Modernize Identity and Access Management (IAM)
Create an IAM API service that acts as a shim between legacy systems and authentication services with Okta to eventually move the enterprise to Okta as the single source of truth where multi-factor authentication (MFA) (using hardware enabled authentication devices such as yubikey) and ZT can be enabled.
To achieve this a middleware application shall be created that pulls IAM data from internal legacy CMS systems and feeds it through an API to Okta, initially creating two sources of truths that should act as a mirror and then eventually phase the legacy authentication and role-based access controls out.
3.2.2 Share Application Data
As CMS moves to fully enabled web applications, an API shall be created to start to warehouse data in various applications. For example, all cyber scheduling app data could be housed in same datastore, and other applications (like CFACTS or Aolytix) could use this data. Alternatively, cyber scheduling could use data from security tooling such as Nucleus, Axonius, or CFACTs that will help to add context.
3.2.3 Create Extensible Middleware to Feed Security Data Lake
Create an API service that takes logging and monitoring data from any type of app or logging and monitoring service (the CMS deems relevant) and feeds it to snowflake, in a normalized manner. The requirement would be for any application teams to send the requested data through the API service so CMS stays agnostic of logging/monitoring tools.
3.2.4 Automation
Leverage the above API objections to automation provisioning and access to various systems and tools. From here, the contractor shall create an extensible & programmatic way to not only allow access to IAM, but how teams automate access to their tools through ZT, SSO, etc.

Status Summary

EAPI team has been focusing on finalizing work on the SONAR application and transitioning attention to EAPI capabilities to include tool investigations (with review), planning of API prototypes to shape what EAPI will look and feel like. We have completed work on our side to support the EMM dashboard enhancements and integration to v2 endpoint

Highlights

Enable ADOs to expose, discover, and integrate with APIs (3.2.4)
EMM team migration to v2 endpoint (should be able to cutover by end of March)
Addition of maintenance mode flag
Share Application Data (3.2.2)
Enterprise API Gateway:
Creating docker compose stacks for gravitee.io and KONG with SONAR API and SONAR agent to interact with the API
Automation (3.2.4)
SPIKE investigation of ways to signal to SONAR that a cluster is being spun down for the night (introduction of maintenance mode)
Add a maintenance flag in the service hierarchy health controller
Update service hierarchy configuration models with scheduled maintenance fields
Added two maintenance status fields to four different API query response models.
Meeting with Infra and TA teams to discuss the addition of maintenance mode status in SONAR to ensure we are aligned and to identify how the display of configuration levels should look
SPIKE investigation on developing a mechanism for knowing how close "respond in < X seconds" is to hitting:
Record HTTP response time from sonar-agent/http health check evaluation
Display response time data fetched for HttpResponseTime health checks
External alerting capability has been deployed!
Successful migration to .net8
Enhancements of current SONAR runbooks and development of additional runbooks
Discovery meeting with Pipeline team for SONAR to be the pilot partner for Github migration.
Mission Enablement support: Troubleshooting to get Streamlit app deployment in AWS functional, documentation update and transfer of information from Crystal, received a partnership with OSORA (Carly Richmond)

Lowlights

Experienced a few weird error messages after external alerting rollout (appear to have been one offs)

Dependencies

We are dependent upon the EMM team to complete the updates on their end in order to finalize and validate the migration to the v2 endpoint.

Risks

N/A

Upcoming iterations and waves Focus

Enterprise API Gateway development
Maintenance Mode Status implementation
Prep for SIGNAL <> CFACTS integration via EAPI gateway (Q2)

Security Data Lake

SDL is pivotal in bolstering the CMS Security Data Lake. Our team brings engineering acumen to delineate business use cases, pinpoint data sets, steer data movement, and set up structured data storage. Moreover, the SDL is undergoing enhancements to cultivate a cost-effective, transparent, and agile cloud-native data lake, vital for security-focused decisions. Integral to this is the SDL's capability to perform ETL functions, amalgamating data from diverse sources for various business sectors to interpret and assess.

Key Objectives/Milestones

3.3.1: Building data governance and data access rules into data lake platform to inform authorization decisions made in alignment to CMS security policy.
3.3.2: Support for a security data lake shall also include the development and operation of extraction, load, and transform (ETL) pipelines to ingest selective data sets into the security data lake.
3.3.3: Deployment and operation of solutions to ingest, normalize, and aggregate data necessary for the cybersecurity mission at CMS

Status Summary

The team continues to develop AskMe ML/AI apps for the data category by integrating snowflake data catalog table. We have made progress on MAG integration by now being able to recieve the subscription data. Akamai plumbing is in place, awaiting files from Akamai team to continue the work. Grype Vulnerability Integration with Watch Tower Phase 1 is nearly complete. We began architecting Near Real Time Gateway API.

Highlights

3.3.1: Building data governance and data access rules
3.3.2: Support for a security data lake
Grype Vulnerability integration
MAG Integration
Akamai Integration
Real Time API Gateway Architecture and POC
3.3.3: Deployment and operation of solutions
AskMe ML/ AI App Development and Enhancements

Lowlights

Coda page updates for clarity on documentation

Dependencies

Awaiting sample JSON Files from Akamai

Risks


Upcoming iterations and waves Focus

3.3.1: Building data governance and data access rules

3.3.2: Support for a security data lake
Successfully established a connection with MAG and progressed onto consuming data into SDL
Created the SDL plumbing (database tables, etc) to begin Akamai Integration
Began Real Time API Gateway Phase 1 build out
3.3.3: Deployment and operation of solutions
Completing V1 AskMe ML/AI App

GRC (Governance Risk & Compliance)

The GRC Team conducts comprehensive research and discovery across CMS’ governance, risk, and compliance processes, people, and technology to identify and articulate challenges, formulate potential solutions, and advance toward implementing feasible and impactful change.

Key Objectives/Milestones

Per contract:
In coordination with the Government, deploy, optimize, and maintain a modernized governance, risk, and compliance (GRC) solution to support CMS compliance needs. This work shall support:
Objective 3.9.1 Complete ADR to select a new enterprise GRC tool
Objective 3.9.2 Ensure that it complies with ARS 5.0 and various NIST frameworks and that it supports an appropriate inheretence model
Objective 3.9.3 Ensure that compliance artifacts can managed and verified through native Open Security Controls Assessment Language (OSCAL) formats
Objective 3.9.4 Deploy tooling within batCAVE infrastructure and that it can be secured per CMS specification
Objective 3.9.5 Ensure that it can be integrated with SSO and ZTA
Objective 3.9.6 Ensure that multiple application development organizations (ADOs) can be supported while still providing CMS an enterprise view of GRC posture
Objective 3.9.7 Ensure that an API is available so integration with other OIT and ISPG technologies can be accomplished to cut out duplicative work being required of other OIT or ADO
Objective 3.9.8 Data sharing via API integrations with other OIT and ISPG technologies to cut out duplicative work being required of OIT or ADO team members

Status Summary

The GRC Team has drafted a project roadmap for FY24Q2 that focuses on improving CMS’ governance, risk, and compliance program. The team began cross-collaboration efforts with other teams; starting with the Division of Security, the Division of Privacy, Policy & Oversight (DSPPO), the Division of Implementation & Reporting (DIR), as well as other teams within the Division of Security & Privacy Compliance (DSPC). The GRC team has started to work on value streams such as the structure for the Governance Committee, creation of the Service Blueprint, and the FISMA FY23 Self-Assessment Maturity Model Analysis. GRC has also continued to create educational content that can be leveraged as learning resources for the ISPG community.

Highlights/Accomplishments

Per Objective 3.9.1
CMS Guide to Federal Laws, Regulations, and Policies Cybergeek page.
Published list of 2024-2019 OMB Memos relevant to CMS.
Service Blueprint
Received updated CFACTS workflow from CFACTS team.
New designer began drafting a more digestible blueprint for users.
New designer began to review and update user personas on Coda/Mural.
Per Objective 3.9.2
FISMA Maturity Level Improvements
Documented FISMA Maturity Level improvement plans & roadmaps.
Risk Management Framework Integration
Reviewed first three steps (Prepare, Categorize, Select) of Risk Management Framework (RMF) with Committee.
Per Committee discussion, team documented improvement plans & tentative roadmaps.
Per Objective 3.9.6
Drafted ISPG Divisional RACI Matrix - Current State
Created a ISPG Divisional RACI Matrix that demonstrates current responsibilities as it aligns to steps within the TLC process.
Matrix identifies pain points and gaps within the processes that need to be iterated on.

Lowlights

Removed objective of SDL<>GRC Integration per program leadership. Bandwidth did not allow for this.
Clarity Service Designers no longer in GRC team.
Had to push FISMA roadmap deadline by one week (now 3/22) due to company retreat.

Dependencies

CMS stakeholders availability to provide feedback on artifacts and products.

Risks

N/A

Upcoming iterations and waves Focus

Continue reviewing RMF with Governance Committee.
Begin validating Risk Management & ICAM FISMA Maturity Levels.
Draft Standardized System Description Template.
Publish list of HHS policies and standards on Cybergeek.
Develop ISCM Structure.

Mission Enablement

We scale secure and proven products / services to enable teams across CMS to achieve their goals quickly and safely, while strengthening our IT security posture.

Key Objectives/Milestones

Status Summary

We are making strides toward design of Project Dogtag (data labeling/tagging), Project Enclave (ISPG private enclave to store critical “security” assets and complete sensitive ISPG functions and activities using Cloud technology) - CANCELED, and Project Harpocrates (differential privacy), (ON HOLD) Project Zeus (threat intel reports)

Highlights

Transition from Doug to Elizabeth
Scheduled new meeting sequence
Review of Mission Enablement documentation and planning next steps
Received a partnership from OSORA (Carly Richmond)

Lowlights

Our data scientist moved on to another opportunity

Dependencies

Dependent on partnership to utilize CMS data for testing

Risks

We will no longer have the support of a data scientist to run ML models - team is prepped to support based on documentation but future of project could be hindered

Upcoming iterations and waves Focus

Discuss future outlook of project
Discuss partnership with OSORA and how we will integrate their data

Enterprise Cost and Scale (Aolytix)

Our Enterprise Cost and Scale team (Aolytix)

Key Objectives/Milestones

The contractor shall, in coordination with the Government, develop capabilities to capture and forecast costs related to infrastructure, time, and data management. This work shall include capturing, modeling, and analyzing data related to cost, tagging of resources, and creating traceability for ownership. This work should inform procurement spend optimization efforts within the Office of Information Technology (OIT) and the CMS Cloud Program.

Highlights

User Documentation:
Continue documentation of other features such as reporting, service and network policy topologies
Kubernetes Log:
Started frontend support for viewing Kubernetes logs
Completed improvements to backend log retrieval performance
UI Improvements:
Completed design review for account, group and user management.
Implement functionality to allow users to resize sections
Enhanced table views to display more data and improve overall readability
Reporting Enhancements
Added support for ordering of columns in reports
Improved report generation performance
IRSA Support
Implement relationship mapping between service accounts and IAM Roles
Decoded IAM manage policy document to support zero trust in IRSA review
Enhanced usability of search results for easier navigation


Lowlights


Dependencies

We did not have any dependencies that impacted work progression

Risks

N/A

Upcoming iterations and waves Focus

User Documentation:
Complete documentation of install and user guide.
Kubernetes Log:
Complete frontend support for viewing Kubernetes logs.
UI Improvements:
Implement frontend of account, group and user management interfaces
Add support for viewing Kubernetes configurations in JSON and YAML.
Search Functionality:
Design and implement search improvements for better user experience.
Kubernetes Status Improvements:
Improve Kubernetes Status indicator. Make it easier to know when access to a cluster is lost.
Reporting Enhancements:
Support for listing account, cluster, and VPC information.
IRSA Support
Conduct usability study on IRSA features.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.