Project Services (Context below)
Software development projects at CMS are responsible for providing the bulk of the services they require. This chapter defines three sets of services in support of software development efforts: cross-project services, minimal required engineering support services, and additional services. The following topics address each set of services.
Cross-Project Services
There are a few services provided for software development that cross projects. The following exceptions are typically cross-project services:
-
Technical review and consultative services provided by the CMS Technical Review Board (TRB)
-
Change control, provided by change control boards (CCB) that coordinate between projects with inter-dependencies
-
Data center support services, provided by the hosting provider (either a VDC or CMS-approved Cloud Service Provider)
-
Database management support services, which include data management support and data modeling
-
Security services, such as Security Control Assessments (SCA) or Adaptive Capability Testing (ACT)
-
Accessibility and Section 508 assessment services
Projects should discuss available cross-project services with their hosting provider because services may vary by provider.
Integrated Engineering Support Services
- Defect Tracking
- Version Control
- Continuous Integration
- Build Automation
- Package Repository
- Test Automation
- Package Deployment
- Accessibility and Section 508 Testing
CMS TRA Services Framework
The CMS TRA Services Framework (see CMS Services Framework) provides a standardized template for implementing systems at CMS. This template or pattern details security and interoperability requirements. The Services Framework architecture enables flexibility while continuing to apply defense-in-depth principles. The services framework applies to CMS data centers and cloud implementations.
The services framework is the basis for the CMS Multi-zone Architecture (see CMS Multi Zone Architecture) where the framework services, detailed by the functions they performed, are mapped to zones within the architecture. CMS is focused on protecting CMS assets via security challenges and enforcing defense-depth-principles. Zones are a way of grouping and sharing resources based on a shared security posture. Distinct zones generally exist in legacy data centers but are not as prevalent in cloud implementations where virtual resources, such as network, compute, and storage are project based implementations and there is tight integration with other cloud service provider (CSP) provided services.
While CMS does not specify the number of zones, CMS does require that CMS data be at least three independent legitimacy tests away from the open Internet. A test is defined as the challenge, filtering and transformation of the data request.
CMS TRA Multi-Zone Architecture
The CMS TRA specifies a zone architecture that provides defense against security attacks and implements layers of challenges to ensure only authorized access to CMS resources. The services framework details the functions provided by each of the service types, and these services are represented by zones in the CMS TRA multi-zone architecture (see CMS Multi Zone Architecture).
CMS does not require distinct zones for protecting assets, but it does require that data is protected by at least three security challenges. This is a minimum requirement, as additional security measures may be helpful in reducing the risk of a security breach.
The complete description of the CMS TRA Multi-zone Architecture appears in the CMS TRA Foundation Business Rules and Network Services section, Security Services topic.
Related CMS ARS Security Controls include: SC-5 - Denial of Service Protection, SC-7 - Boundary Protection, and SC-32 - Non-Mandatory: Information System Partitioning.
Web Services or APIs
The CMS TRA describes a service-oriented architecture, supporting both interactive and batch processing modes. The Web Services topics in this chapter provide a more detailed description of web services.
SOAP web services should be documented with separately controlled Web Services Definition Language (WSDL) files (even if initially auto generated). XML-based REST (Representational State Transfer) services can be documented with WSDL 2.0 (or later) files. Java Script Object Notation (JSON)-based services can be described using JSON Schema.
Related CMS ARS Security Controls include: SC-8 - Transmission Confidentiality and Integrity.
Enterprise Messaging
Use of enterprise messaging is recommended for CMS applications. JSON based enterprise messaging increases security by abstracting object locations, moving data access logic closer to the database and requiring business applications to access data via message-based services rather than by direct SQL statements. This helps reduce vulnerability to SQL-enabled exfiltration of data and SQL injection attacks. Enterprise messaging provides additional resilience for applications because it allows for asynchronous coupling between sender and receiver. When enabled, enterprise messaging can provide guaranteed delivery of messaging where messages are transmitted in store-and-forward manner. Thus, if a receiver is unavailable, messages intended for that receiver are not lost. Instead, they are queued to disk and delivered once the receiver is ready. Of course, this is not optimal if the originator no longer needs the response, as is typical with web applications where a response is required quickly before users lose patience and either resubmit or terminate the sessions. Finally, enterprise messaging provides location transparence and decoupling of the service provider from the service consumer. This enables flexibility in the deployment architecture without application changes.