System maintenance challenges
Organizations which perform regular security maintenance on their systems can benefit from improved data protection. They’re also more likely to have strong alignment between their security objectives/standards and their IT operations. It can be challenging to manage the security tasks, especially in heterogenous environments running a variety of software, and special system requirements for handling systems processing sensitive data (health data, financial, etc) or systems supporting critical business processes with limited downtime. Tooling and automation are necessary, but sometimes increase complexity. Some key questions:
- How does IT know when to do what?
- What are the security requirements for each system or group of systems?
- How do Operations teams know they’ve done everything necessary for a task?
- Where can your team find current task-specific instructions?
Solution: System Security Plans
One solution to guide IT and consistently answer these questions is to create a System Security Plan (SSP). NIST defines an SSP as a “formal document that provides an overview of the security requirements for the system and describes the security controls in place or planned for meeting those requirements” (NIST SP 800-12 Rev. 1). An SSP can be scoped to a single system, a few critical systems or a large group of systems. The SSP is the security plan for the systems within its scope, a tool to help communicate the security objectives and how they are managed. SSPs can be a useful tool whether your technology is in the cloud, on-premises, or a hybrid.
Benefits of System Security Plans
SSPs can help personnel make technology decisions that positively impact security, implementing their organization’s security requirements. SSPs offer significant returns on the investment of keeping them updated:
| Vulnerability management – quickly identify systems impacted by new vulnerabilities
|
Business continuity – resilience planning and disaster recovery
|
|
Efficient and consistent operations – know what technology you have and how to manage it
|
Insights – fast responses to leadership inquiries and requests for audit evidence
|
To illustrate this, consider an organization seeking to deploy new system or network monitoring tools to improve risk management. IT would review the system’s software inventory, network diagram, data description and configuration associated with the SSP, to help them make informed tooling and deployment decisions more quickly.
Creating your System Security Plan
To establish an effective SSP, leadership should first determine the scope based on business criticality of the processes that systems support. After selecting a critical process, identify systems primarily used in the process, as well as the indirect dependencies that those systems have, as described in guidance for prioritizing business-critical risks. It is also essential to engage all the relevant stakeholders, include the business leaders and IT teams supporting these systems. Once the right contacts are engaged, these are some recommended steps for establishing an SSP:
- Communicate the leadership decisions about the scope of systems in your SSP
- Use the template in NIST Special Publication 800-18 “Guide for Developing Security Plans for Federal Information Systems” or select relevant sections in table 1 below.
- Define and implement processes for:
- Creating new SSPs
- Gathering and maintaining the associated system documents (see table 2 below)
- Managing change to keep the systems and SSP synchronized (an inaccurate SSP is not helpful)
Maintaining System Security Plans
SSPs should be dynamic living documents. A good approach is to include an appendix with the history updates that were made, tracking the date and details of changes. Because the SSP needs to be kept current, it is a good idea to create a procedure for the different elements that will be continuously updated. For example, if monthly vulnerability scans are part of the SSP, decide how the new scan is added and the old one is archived.
SSPs for Oracle Cloud Infrastructure (OCI) customers
Planning how you’ll secure your OCI tenancy is essential for success. An SSP gives the structure for defining what security controls to implement, how to configure the storage, networks, databases, compartments, and other OCI resources. It also captures assignment of roles and responsibilities for tenancy management, monitoring, and tracks implementation of planned controls. To build an SSP for using OCI, it can be helpful to:
- Start with these security recommendations
- Decide how you want to use authentication credentials and assign responsibilities
- Configure alarms and monitoring to appropriate thresholds
- Define Cloud Guard detection criteria and associated response
- Plan use of audit logs and analysis tools
Table 1: SSP sections from NIST SP 800-18
| Section |
Focus |
Details |
|
| 1 |
Information system name/title |
Unique identifier and name given to the system. |
|
| 2 |
Information system categorization |
Identify the appropriate FIPS 199 categorization (low, moderate, high) or your organization’s categorization |
|
| 3 |
Information system owner and contact information |
Name, title, organization, address, email address, and phone number of person who owns the system |
|
| 4 |
Authorizing official / approver |
Name, title, organization, address, email address, and phone number for the senior leader eligible to authorize the SSP |
|
| 5 |
Key personnel, or other designated contacts |
As applicable, include their title, address, email address, and phone number |
|
| 6 |
Assignment of security responsibility |
Name, title, email address, and phone number of person who is responsible for the security of the system |
|
| 7 |
Information system operational status |
If more than one status is selected, list which part of the system is: Operational, under Development, or Major Modification |
|
| 8 |
Information system type |
Indicate if the system is a major application or a general support system. If the system contains minor applications, list them in Section 9 |
|
| 9 |
General system description, purpose and function |
Describe the function or purpose of the system and the information it processes as wells as components, boundaries, network architecture, and user types. |
|
| 10 |
System environment |
Describe the technology, including the primary hardware, software, and communications equipment, and data flows. Specify acceptable ports, protocols, and services. |
|
| 11 |
System interconnections |
List interconnected systems, system identifiers, including the system name, organization, system type (major application or general support), data direction (incoming, outgoing, or both). |
|
| 12 |
Related laws, regulations, standards, and guidance |
List any laws or regulations that establish specific requirements for the confidentiality, integrity, or availability of the data in the system |
|
| 13 |
Minimum security |
Describe how all security controls are being implemented or planned to be implemented:
|
|
| 14 |
SSP completion date |
Completion date of the plan |
|
| 15 |
SSP approval date |
Enter the date the system security plan was approved. Indicate if the approval documentation is attached or on file. |
|
Table 2, Associated SSP Documents
| Document |
Description |
| Network diagrams |
Show all networking devices, includes device name, model#, build#, OS, IP, device owner contact |
| Data flow diagrams |
Show the ingress/egress of the data, including external and internal (between systems) movement |
| Data ownership matrix |
Data type and location, and owner’s contact |
| Boundary diagrams |
Scope boundary of the infrastructure |
| User roles matrix |
Types of users and their roles |
| Inventory list |
Lists all devices, including device name, model #, build#, OS, IP, device owner contact |
| Ports, Protocols, and Services list |
Identify (by device) ports, protocols, and services that are enabled, note which ones are to remain disabled at all times |
| System baselines |
Approved configuration (by device). This may be a downloaded copy of the OS (in its approved configuration), or could be snapshots of approved configurations, or describe how system baselines are stored and where. |
| Security templates |
Security configurations (by device) |
| System access matrix |
User type and associated access (per device), This specifies what roles will have access and what each role enables or can do |
| System maintenance, update, and patching schedule |
Schedule (per device) for maintenance, updates, and patching |
| Tool inventory |
Lists tools used (per device) to maintain and test the system, including tools that are automated, native to the system, and manual (i.e. disk, etc). Specify all types of maintenance and testing. |
| Interconnection agreements and/or supplier/vendor agreements |
Collect agreements for interconnections and supplier/vendor agreements with access to systems |
| Supplier/vendor inventory & contacts |
Identify suppliers/vendors providing services that impact the infrastructure and their contacts |
| Laws, regulations, standards applicability matrix |
Identify the laws, regulations, and standards that are applicable to the SSP scope |
| Security controls matrix |
List implemented security controls and all control owners contact |
| Business Continuity Plan |
Identify which BCP supports the scope of the SSP |
| Disaster Recovery Plan |
Identify which DRP supports the scope of the SSP |
| System emergency procedures & contacts |
Define emergency procedures (per device) and contacts needed during emergency. These are simple steps, such as shutting down a system within the uninterrupted power supply (UPS) time period. |
| Risk assessment & treatment plan |
Identify the Risk Assessment and Risk Treatment Plan in private-sector or a Plan of Action & Milestone (POA&M) for public-sector |
| Change management emergency procedures & contact |
Detail the emergency change procedures (per device) and contacts needed during the emergency change |
| Audit reports |
Archive a copy of all audit reports, or attestations for SSP scope |
Resources
These resources can help you build your SSP(s):
- NIST Special Publication 800-18, Guide for Developing Security Plans for Federal Information Systems
- NIST Special Publication 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
- FedRAMP System Security Plan (SSP) Required Documents
Learn more about Oracle Cloud Infrastructure:
- Service Essentials
- Download OCI audit reports and other compliance documents