Compliance Change Management

security-related project that demonstrates the skills of communication, technical judgment, and cross-functional change management as applied to implementation of a “thorny compliance requirement”.

Within Rev 5, FedRAMP has modified the requirement to implement a Controlled Access Area (CAA). The changes in Rev 5 make compliance with the physical protection requirements considerably easier to attain.

SC-8

A PaaS/SaaS can leverage the CAA as follows:

• The CAA, and encryption between data centers, as necessary, must be authorized by the IaaS/PaaS CSPs before it can be leveraged as inherited by customers

• As described above, the IaaS CSO documentation must document that SC-8, SC-8(1), and SC-8(5) are inheritable “as a set” for DIT protection, that is, all three must be in place.

• The documentation must clearly state that the following is in place:

  • CAA per SC-8(5) for all data centers where DIT may traverse

  • DIT encryption is in place between data centers where:

    • The encryption is FIPS 140 validated

    • The encryption termination points are inside the CAA envelope in all data centers

    • Independent assessor validates all of the above

Situation:

Our team faced the challenge of maintain FedRAMP Moderate compliance for our Kubernetes cluster on AWS, with a specific focus on encrypting data in transit. Compliance with controls SC-8 and SC-13, which require FIPS-validated encryption for data protection, was critical.

AWS App Mesh, introduced significant complexity and performance overhead, making it difficult to meet these requirements efficiently.

Complexity in Managing Microservices Communication

• AWS App Mesh introduces complexity when managing communication between a large number of microservices. Configuring and maintaining mTLS for secure communication between services can become cumbersome and error-prone, especially as the number of services grows.

• AWS Nitro simplifies the environment by providing secure, isolated, and performant EC2 instances where communication can be securely handled at the infrastructure level. By using Nitro instances, you eliminate the need for service mesh-specific configurations, as data is encrypted in transit and at rest by default, reducing the complexity of securing microservice communications.

Performance Overhead due to Service Mesh Layer

• App Mesh Issue: The additional service mesh layer in App Mesh can introduce latency and performance overhead, as each service call must pass through a proxy. This can lead to degraded performance, especially in latency-sensitive applications.

• Nitro Resolution: AWS Nitro offloads many of the virtualization tasks to dedicated hardware, which reduces overhead and increases performance. Nitro instances provide near-bare-metal performance by minimizing the hypervisor's role, which is crucial for high-performance applications that might suffer from the overhead introduced by App Mesh.

Operational Complexity

• App Mesh Issue: Managing a service mesh requires additional operational overhead, including configuring and maintaining proxies, handling service discovery, and ensuring that all services are correctly enrolled in the mesh. This complexity can lead to potential misconfigurations and increased management burden.

• Nitro Resolution: AWS Nitro reduces operational complexity by offloading tasks like encryption and security enforcement to dedicated hardware. Nitro's architecture inherently provides isolation and security without the need for additional service mesh layers, simplifying the management of your environment.

Lack of Transparency in Data Encryption

• App Mesh Issue: In App Mesh, while TLS can be enforced, ensuring transparency in how and where encryption is applied can be challenging. Ensuring that all data paths are encrypted requires careful monitoring and configuration.

• Nitro Resolution: With AWS Nitro, encryption is built into the hardware, and all data at rest and in transit is automatically encrypted. This ensures full transparency in data encryption, as users can trust that all data is secured without needing to monitor individual data paths actively.

Task:

The primary challenge was to fulfill these compliance requirements while addressing the operational overhead and complexity introduced by our existing solution, AWS App Mesh. App Mesh added significant complexity and performance overhead, which made it difficult to achieve compliance efficiently. And also developing a project plan.

Action:

I spearheaded the initiative to find a more efficient solution. After extensive analysis, I identified that transitioning to AWS Nitro instances would effectively meet our requirements. Nitro instances support FIPS-validated encryption modules, aligning with SC-13's requirements. My role involved:

• Technical Evaluation: Analyzed the technical implications of moving from App Mesh to Nitro instances. App Mesh added overhead due to its service mesh architecture, which required additional configuration and introduced latency due to its interception and routing of traffic through its control plane. Nitro instances, on the other hand, provide built-in support for FIPS-validated encryption directly within the hardware, eliminating the need for additional encryption layers and reducing latency.

• Collaboration: Worked with the DevOps team to implement Nitro instances across our EC2 hosts. This involved configuring instances to utilize Nitro’s FIPS-validated encryption modules, ensuring compliance with SC-13. We also evaluated Nitro's compatibility with our Kubernetes setup and ensured that it integrated smoothly with our existing infrastructure.

• Configuration: Ensured ingress traffic was managed through NGINX using FIPS-compliant OpenSSL libraries, and handled egress traffic by routing it through FIPS-validated endpoints or ensuring proper encryption for sensitive data. This setup addressed the limitations of App Mesh by simplifying the traffic encryption process and reducing the need for additional configuration.

Potential Technical Issues:

• Encryption Efficiency: Nitro instances offer hardware-based encryption directly integrated into the hypervisor, significantly reducing the overhead associated with encryption compared to App Mesh. App Mesh required encryption to be handled by separate components, adding latency and complexity. Nitro’s approach streamlines encryption and decryption processes, improving performance and efficiency.

• Performance Impact: Nitro instances improved performance by offloading encryption tasks to dedicated hardware, minimizing the impact on instance resources. In contrast, App Mesh introduced additional latency and performance overhead due to its service mesh architecture and traffic interception.

• Operational Complexity: Nitro instances reduced operational complexity by integrating encryption at the hardware level, eliminating the need for extensive configuration and management of encryption layers. App Mesh required additional setup and management for encryption and traffic routing, adding to the operational burden.

• Compatibility and Integration: Nitro instances were compatible with our Kubernetes setup and AWS services, ensuring seamless integration and compliance. App Mesh required more complex configuration to align with compliance requirements, making Nitro a more straightforward solution.

8 Months

Design and Architecture Planning

• Target Architecture Design: Design the new architecture leveraging AWS Nitro, including network architecture, security configurations, and instance types.

• Service Mapping: Map current App Mesh services to Nitro-based infrastructure.

Test and Pilot Phase

• Setup a created mirror environment in a separate AWS account.

  • Perform extensive testing, including functionality, load, security, and compliance testing. Gather performance metrics and compare them with the current environment.

• Setup Nitro Environment: Deploy a pilot environment using Nitro-based instances and infrastructure in the federal

• Pilot Migration: Migrate a small, non-critical subset of services from App Mesh to the Nitro environment.

• Testing and Validation: Perform extensive testing, including functionality, load, security, and compliance testing. Gather performance metrics and compare them with the current environment.

Full-Scale Migration Planning

• Final Migration Plan: Develop a detailed migration plan based on insights from the pilot, including a phased approach for migrating all services.

Phased Full-Scale Migration

• Phase 1: High Availability Services: Begin with services that are critical but have redundancy to ensure minimal impact.

• Phase 2: Core Services: Migrate core services that are essential for business operations.

• Phase 3: Low-Risk Services: Conclude with low-risk, non-critical services.

• Continuous Testing: Perform testing after each phase to ensure stability and compliance.

Result:

The transition to AWS Nitro instances was successfully executed, leading to improved performance, reduced operational complexity, and compliance with FedRAMP encryption requirements.