The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.
FedRAMP is required if organization is planning to have projects from US FedRAL Government. It is also a framework to harden organization’s infrastructure.
Getting FedRAMP is pretty long process. This process may require organization to revamp it’s infrastructure. Many times due to unawareness of technical impact, we estimate the timelines inappropriately, which may affect organization’s running workload.
This small note will help to understand basic technical requirements for FedRAMP certification. It will also help Organization’s technical people to plan their timeline accordingly for implementing FedRAMP Controls.
Note that this is a very basic list of technical stuff required for FedRAMP. Make sure you have these basic things in placed before going for FedRAMP. This will help you to save time for FedRAMP compliance.
- In AWS not all regions are FedRAMP certified. GovCloud is fully FedRAMP compliant region. Us-east & us-west are FedRAMP ready regions and will get compliance in future. Check this for more details https://aws.amazon.com/compliance/services-in-scope/
- I have considered organization’s infrastructure is in AWS, however many common things can be used for InPremise as well.
For any queries or suggestions, do contact me on ngurjar[at]neeleshgurjar[dot]co[dot]in
- Documentation is very crucial part of FedRAMP. Every control, every object should be properly documented.
- Organizational level documentation
- Roles and Responsibilities of users
- Network and Application architecture along with Diagram with showing boundaries
- Evidences of whatever you have configured for FedRAMP
- Listing and tracking of whatever documents FedRAMP asks for
No Shared Accounts, Restricting & Tracking all Access:
In cloud infrastructure, many times shared users are configured by default eg. ec2-user, ubuntu, etc. These users are always configured to use privilege access. If a single account is used by multiple users to login in, then it is difficult to track “who did what”. To avoid this:
- All shared accounts such as ec2-user, ubuntu should be limited and documented.
- All users should be able to login with their accounts either via SSH or Web Console
- Access to users should be restricted and if previleged permissions are given then should be properly documented.
- User information can be centralized or decentralized but should be easily managed.
- In AWS users should have restricted access to AWS resources and properly documented.
- Roll based access should be configured in AWS. For eg. Instead of using Access and Secret Keys, access should be provided via Instance Roles.
- Centralized Authentication can be configured using AD or using Configuration Management system. CM will push users and SSH keys to all instances. We also can store SSH keys in IAM instead of instance’s volume.
- SSH Keys should be rotated after some interval.
Multi Factor Authentication (MFA):
- MFA should be enabled for all users for all types of logins such as AWS console, Application portal, SSH, etc.
- Users without MFA should be disabled
Logging and Monitoring:
- OS audit logs, AWS API and VPC flowlogs should be enabled and it should capture user activities, login failures, privilege functions, network activities etc.
- Logs should be stored centralized location
- Logging system should alert if any malicious activity found
- Logs should be easily searchable
- Log retention should be configured
- For OS logging Services like rsyslogd, syslog-ng can be configured to redirect audit and user level logs to one Centralized location such as Graylog or ELK cluster.
- For AWS API logs CloudTrail, SNS, SQS and for VPC flow logs Kinesis, other services can be used with Graylog
File Integrity Monitoring:
File Integrity Monitoring (FIM) is required to track or monitor changes to files and notified for unusual changes in critical files.
- FIM needs to be configured on every instance / VM.
- FIM system should notify if any monitored file changes.
- There are mainly 2 approaches for this. 1. Monitor all and exclude many or 2. Monitor selected directories and exclude other.
- Alert notification can be configured either in FIM server or Audit logging server.
- OSSEC server-client setup can be useful for File Integrity Monitoring.
CIS compliance Images / OS:
- Underlying OS should be CIS compliant.
- CIS is for “Center for Internet Security”. It is an organization which Identify, develop, validate, promote, and sustain best practice solutions for cyber defense.
- You can download CIS benchmarks from https://learn.cisecurity.org/benchmarks
- Level 1 controls are sufficient for FedRAMP compliance.
- This process takes major time. It includes enabling SElinux, Firewall also creation of separate partitions for /var, /var/log, /tmp, etc.
- Some of the controls requires reboot or creation of new instances.
- As there are many OS level changes, application testing should be done thoroughly, after implementing CIS changes.
- Instead of implementing all controls, CIS certified Images are already available on AWS marketplace as well.
- Continuous Monitoring for CIS compliance should be configured.
OS and AWS hardening:
- Password complexity, length, age (expiry) should be enforced.
- Account disabling after multiple login failures should be in placed
- Multiple Login failures should be tracked.
- SELinux along with Firewall need to be enabled and properly configured.
- Passwdqc can be mainly used for this along with PAM.
Baseline Configuration of Application and Infrastructure:
- FedRAMP requires baselining configuration of Application and Infrastructure as well.
- Configuration management should be in placed for this.
- It requires, to retain previous versions of Application and Infrastructure deployment configuration. Also operations guys should be able to easily rollback to previous versions of application and infrastructure.
- Application should be deployed in form executable / artefact. So that it will help to create versions and configure point in time restore.
- CI-CD always helps for storing baseline configuration.
FIPS 140-2 Compliance:
- FIPS 140-2 is basically for maintaining cryptographical standards, such as only TLS1.2 onwards should be enabled and not previous versions
- It is must whereever ingress points are defined, such as ELB, Proxy servers, Gateway, etc.
- In AWS SSL termination at ELB is not FIPS compliant. For this one should not terminate SSL on ELB. It should get terminated at Server level. ELB should be used for just forwarding HTTPS traffic.
- SSH server should have only FIPS certified Cyphers enabled.
- Data should be encrypted on S3
- EBS volumes should be encrypted
- Where application or CM stores passwords, they should be saved in form of FIPS140-2 compliant encryption.
- In AWS KMS encryption is FIPS140-2 compliant. We can store Keys in KMS and use them for encryption.
Fault Tolerance and DR:
- For FedRAMP, our infrastrucure should be configured in Highly Available and Fault Tolerant manner.
- Infrastructure should be spin up across Availability zones in AWS. So that if AWS will make sure to spin up all services on different hardware in different datacenters.
- DR should be properly configured and well documented.
- In DR RPO and RTO should be well defined.
Continuous Vulnerability Scanning:
- FedRAMP requires that whole infrastructure should be monitored for Vulnerabilities and notified if any breach found.
- Tools like Nessus should be configured for Periodic Vulnerability Scanning