In recent years, many DevOps teams with CI/CD pipelines have started exploring Security/Compliance for Government Agencies on their own through the addition of:
- static source code scans in their pipelines (Coverity, PMD, SonarQube, Yasca, etc) and
- traditional dynamic OWASP authenticated web application scans (BurpSuite, Acunetix).
Consider a hypothetical company, Let’s Dev!, and that they already perform these steps as a part of their SDLC process. The Let’s Dev! Development team is thinking, “Compliance is removing vulnerabilities from the software, no?” There could be a rude awakening when Let’s Dev! receives a FedRAMP/DoD Compliance Gap Analysis report which highlights that these initial vulnerability remediations are a step in the right direction, however, they only start to cover a portion of the Risk Assessment (RA) control family amongst the seventeen other compliance control families that Government Agencies require to migrate their critical workloads onto the Let’s Dev! web application. A handful of common technical (non-policy/documentation related) hot spots for DevOps teams like Let’s Dev! that we usually see are below.
COMPLIANT AUTHENTICATION (IA-2, IA-8 and their enhancements)
Cloud Service Provider (Org) Privileged, and Non-privileged users must authenticate to the system using multifactor authentication. This multifactor authentication must be done on a device that is separate from the one the user is logging into the system with. Common solutions for this are TOTP, Smart Card, PIV card or Common Access Cards.
For Agency or customer users (Non-Org), the Application must provide agencies with a way to authenticate using their existing PIV or CAC infrastructure and any FICAM or PIV interoperability profiles that agency currently uses in their IA infrastructure. This is often achieved via ADFS Federation.
FIPS VALIDATED ENCRYPTION (IA-7, SC-13)
The Software must use only FIPS-validated cryptographic modules, especially for encryption pertaining to authentication.
MULTITENANT APPLICATION SEPARATION (SC-4)
The Software provides rigorous logical data separation between customers to prevent unauthorized and unintended information transfer between tenants (exploits attempted annually by 3PAO penetration testing team).
LOGGING (AU-2)
The Software must be able to generate logs for all application administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes. The logs must be sent to a centralized logging solution and reviewed continuously by a 24×7 Incident Response Team which simulates IRP tests annually.
CHANGE CONTROL FOR PRODUCTION ENVIRONMENTS (CM-3, SA-10)
Pre-approval by a Change Control Board is required for any change made by a Software Vendor administrative user to configuration items defined in the System Security Plan or Configuration Management plan which typically includes inventory changes including network/compute assets, application updates etc. Administrative access to production environments must be controlled and monitored to ensure that only authorized changes are implemented.
Separate from the standard FedRAMP control families, other course-correcting constraints could be uncovered down the road, depending on the Agency:
Common Access Card (CAC) & PIV Card Authentication:
In the case of Federal Agencies using Government-issued CACs as primary authentication or MFA (in absence of ADFS Federation), the application’s leveraged authentication solution must support the Agency’s custom Certificate Root Authority and any intermediate certificates (or DoD PKI) as well as map the CAC PIV Authentication certificate to the application user.
Boundary Cloud Access Point (BCAP) & Supporting Requirements:
If one of the Federal Agency’s physical networks require a private connection to the application that does not go over the public Internet (unlike most VPNs), then the solution architecture now requires fulfilment of a (sometimes years long) process to secure access to their specific BCAP as a Cloud Service Offering (CSO). If the Federal Agency also needs DISA IL5 compliance, additional teams need pulled in to secure this connection to the DoD NIPRnet, such as receiving a dedicated NIPRnet IP block, setting up an approved Virtual Datacenter Security Stack (VDSS), continuous monitoring and DoD approved Host Based Security System (HBSS), etc.
Let’s assume Let’s Dev! decides to tackle at least the technical controls in-house – the application is a greenfield project, and they won’t need to retroactively enforce compliance on a large existing enterprise solution with an existing customer base that can’t suffer downtime or performance degradation. The team soon finds out that Azure offers their own FedRAMP Moderate Blueprint using Azure Policy definitions – however, the Blueprint itself covers only 27 out of 325 controls, and only for a portion of their PaaS offerings.
To get to market as quickly as possible with a specific Agency, the team will likely squeeze in extra hours to not only develop the application on time and budget, but now they also must research and implement manual “right-click publish” compliance configuration of solutions for their environment. If customer demand grows for the product, the manual configuration hardening steps previously performed for the first Agency or POC will need completed again for each new deployment, causing the setup and ongoing workload to scale linearly with the demand. They must also ensure adequate staffing for a Change Control Board, Incident Response Team, Contingency Plan Team and Audit Preparation team, diverting focusing from the company’s original mission – the application itself.
Solution:
As you progress on your journey with serving FedRAMP/DoD Azure solutions to customers, you will eventually have to shift from manually managing the provisioning/compliance/monitoring/support life cycles in Azure using either the portal or the trusty one-off Azure PowerShell/AZ CLI scripts to something more repeatable at enterprise scale. Currently, two of the predominant approaches to managing systems at scale in the cloud are:
- Infrastructure as Code: The practice of building and maintaining infrastructure (mainly the connection topology) by defining all assets as idempotent source code in version control, usually leveraging Azure Resource Manager (ARM) templates, on which other well-known third-party tools, such as Terraform, can capitalize.
- DevOps: The union of people, process, and products to enable continuous delivery of value to our end users.3
The Project Hosts EasyButton is an automation package, a Compliance as Code (CAC) solution which leverages Azure DevOps, Azure Lighthouse and ARM Templates to deliver standardized Azure compliance in a scalable fashion, for either new Azure Tenants or existing ones.
For more information on our FedRAMP Authorization as a Service, contact us at: sales@projecthosts.com
