System Security Plan (SSP) Information#
Systems that fall under the CU Data Classification of Confidential Information or Highly Confidential Information are required to provide a System Security Plan (SSP). An SSP is a document that outlines how an organization protects the security of a system. An SSP is a critical document that helps organizations meet compliance requirements.
Look here for more information about Data Classification.
OIT’s IT Security group is responsible for guiding and evaluating your SSP. IT Security prescribes the NIST SP 800-171 Rev. 2 control set as the official standard to meet compliance requirements for Confidential Information and Highly Confidential Information.
Getting your SSP completed and approved is not only necessary, but can be a rigorous process. The good news is that by using the OIT Research Computing Cloud Foundations Service (CFS) LCA1 solution, some of your security burden is handled by our service.
The CFS LCA1 solution is an AWS Landing Zone that is approved to support Confidential Information. Support for Highly Confidential Information is on the horizon.
The rest of this document will discuss how the CFS service can help you meet some of your security requirements. We also have a guide to help you get started on your SSP journey.
Contents#
CFS LCA1 Features#
The OIT Research Computing Cloud Foundations Service (CFS) team owns and manages an AWS Landing Zone specifically designed to enable support of the NIST SP 800-171 Rev. 2 control set. By using the CFS LCA1 service, we help you meet some of your security controls. Below is a list of features we offer that can help you with your SSP.
Important
Using the CFS LCA1 service does not automatically make your system compliant. Our system is a foundation that enables you to be compliant.
Note
As a best practice, we recommend a separate LCA1 account for each workload environment (prod, dev, test, etc.)
Federated Identity and Access Management (IAM)
When using the CFS LCA1 landing zone, role access is integrated with the CU Boulder OIT Identity and Access Management (IAM) offering. This offering gives you:
Single Sign On (SSO) using your CU Boulder IdentiKey. The role we provide you is set up with temporary short-term credentials to help you meet compliance and best practices.
Access management via Enterprise Access Management (Grouper). Audit logging for federated access is handled by the Grouper service.
You have full control over who can access your AWS accounts.
AWS Root Account User Protection
CFS secures the AWS Root Account User for all your LCA1 accounts. We add MFA to the Root User. We securely store and rotate the password. We have alarms set up to detect any usage of this important and powerful admin user. Our internal procedures ensure that the root user is only used for approved use, requires approval, and is only used for very rare cases. For a list of things that only the root user can do, see this page. In the rare event that any of these actions are needed, rc-support@colorado.edu can assist with submitting a ticket with the CFS team.
Centralized Audit Logging
When using the CFS LCA1 landing zone all user, role and service actions are centrally recorded and stored with the proper data retention and audit policies. This includes actions in the AWS Console, the AWS CLI, and AWS SDKs and APIs. For more information, see AWS CloudTrail documentation. This feature allows you to focus on your application logging without the need to build and maintain an extra audit logging layer.
As an added bonus, any CloudWatch Logs you create will be centrally logged with the proper data retention and audit policies. See the AWS Centralized Logging documentation for more details.
Managed Network and Firewall
When using the CFS managed AWS VPC, you have a private subnet with an encrypted connection to the CU Boulder campus. You also get a internet subnet that we manage. Both subnets are inspected by a firewall. Both inbound and outbound traffic are inspected. The firewall and campus connection are managed by a partnership with OIT Network and Internet Services.
For more information about this feature, see the LCA1 Network Information page.
Training and Support
The OIT Research Computing Support Team is eager and ready to assist with training for you and your team in public cloud usage. RC User Support also provides support services to help give advice and troubleshoot various cloud services. RC User Support can also help with billing and cost optimization.
Note
We maintain a Cloud Foundations NIST 800-171 Customer Guide that provides more information about how our service features map to security controls and recommendations for addressing those controls in your SSP.
Our service features can supplement your work to address each security control, but they do not automatically ensure compliance. Full compliance is dependent upon the details of your application and review from OIT Security.
Please contact us at rc-help@colorado.edu to request access to the guide.
Not sure where to start with your cloud journey? RC User Support is here to guide and assist! Reach out to us at rc-help@colorado.edu.
Getting Started#
Beginning your SSP can be intimidating, but there are strategies your can take to set yourself up for success and streamline the process. These are the steps we recommend for working through your SSP.
Prepare for the SSP#
Before you begin, make sure you have the necessary technical infrastructure and social processes defined to act as a consistent, coordinated team.
Identify a service owner. Your service needs a single person to be accountable for implementing and operating the service. This person will ensure security work is actually implemented and make the final decision about when to move forward after IT Security review.
Define your service. You need to nail down exactly what you will be securing. What are all of its features? Who consumes it? What other services does it integrate with? You need to detail precisely what the service does so you can secure each of those aspects.
Determine the Data Classification for your service. This informs what security controls will apply to your SSP.
Select an internal documentation platform. You will need to generate lots of process documentation that IT Security can review, and that your team will use for securely operating your service. Make sure this is in one standardized location.
Select an external documentation platform. You will need to publish documentation for your users about how to securely use your service and what’s expected of them.
Select a work tracking system. You will need to coordinate on numerous tasks as a team and be able to reliably complete recurring work.
Select a monitoring and alerting system. You will need to make sure your service is operating as intended in an ongoing manner and scan it against standard security baselines. Make sure your alerting is flexible enough to handle different tiers of alerts and different sets of recipients.
Select an events management system. Alerts from your monitoring system need to end up somewhere that the entire team can see but enforces accountability for dealing with them. Make sure the team has a process for selecting who handles notifications and how that is tracked.
Select a configuration management system. Reviewers of your SSP will want to see evidence of how all aspects of your system are configured. If you can manage changes and tracking in a central configuration system, it will be much easier than trying to document and enforce manual processes.
Select a change management system. Establish practices as a team for how you will track changes to your service and the infrastructure that supports it. You will need to ensure changes can be audited and rationalized.
Select a system for tracking your SSP. You’ll need to keep track of each control and how that is met by your team. The SSP will need to be updated periodically as part of ongoing reviews and service changes. Choose something that supports sorting and filtering, not a Word document.
Note
Example Preparation Tools
Here are some tools you might consider for implementing the systems above. Think about what your team already owns or has access to. Think about what data you plan to store in each tool and make sure that follows the appropriate security guidelines. These are examples, not endorsements.
Internal documentation platform:
External documentation platform:
Your existing public website
Work tracking system:
Monitoring and Alerting system:
Events management system:
A shared email inbox with manual accountability processes
Configuration management system:
Change management system:
A manual change log with an established process
System for tracking your SSP:
A spreadsheet
A database
Implement the SSP#
The next step is to stand up your service, creating the necessary security control implementations and documentation.
Get the latest controls. Reach out to IT Security to get the latest official list of required controls. Import this into your SSP tracking system. Confirm which subset of the controls apply to your service (usually based on data classification and service criticality).
Learn about shared responsibility. Read and understand the Shared Responsibility Model.
Stand up your service. Get an account on LCA1. Reach out to rc-help@colorado.edu so that we can gather basic questionnaire information about your workload. Build out your service on AWS, but do not put any non-public data in yet.
Secure your service. Implement each of the required security controls by appropriately configuring your infrastructure, establishing team processes, and documenting everything. Ensure your documentation provides enough detail an auditor can use for evidence of proper implementation. Consider using references to your configuration management system and screenshots where appropriate.
Review the SSP#
Finally, review your SSP implementation with IT Security. After they have reviewed, the service owner can decide if it’s appropriate for non-public data to be introduced to the service.
Review. Request an SSP review from IT Security. Work with them to fix any gaps in the plan. If there are gaps that can’t be addressed, work with IT Security to draft a Plan of Action and Milestones (POA&M) for those items or document the additional risk that gap creates.
Approve. After IT Security has reviewed the SSP, they will make a recommendation to the service owner. At that time, the service owner should weigh the SSP status with the outstanding risks to decide if the service should proceed with hosting non-public data.
Operate. Once the service owner has approved the SSP, the service can begin operating with non-public data. Regular tasks, as outlined by the SSP, should be integrated into ongoing service operations.
Important
A POA&M is essentially a promise to address a security gap in the future. It must have a plan and a due date. IT Security should be notified about completed POA&Ms, and they should be updated in your SSP.