Understanding FedRAMP security impact levels and baselines

You would never pay $1,000 upfront and $30/month for a security system to protect a shed containing $100 worth of lawn equipment. However, you wouldn’t hesitate to spend that much or more to protect your home and family. The same concept applies in information security. Different kinds of data necessitate different levels of security, which is why FedRAMP security impact levels exist. A government agency that deals with data that is widely available for public consumption doesn’t require as many security controls as an agency that works with classified data.

There are three FedRAMP security impact levels: FedRAMP Low, FedRAMP Moderate, and FedRAMP High. They are based on the three FISMA security objectives outlined in the Federal Information Processing Standard (FIPS199):

• Confidentiality: Protect personal privacy and prevent the unauthorized disclosure of proprietary information.
• Integrity: Prevent the unauthorized modification or destruction of information.
• Availability: Prevent disruptions to information access or use.

FedRAMP Low Security Impact Level

The FedRAMP Low Impact Level applies to cloud service offerings (CSOs) that will be used to work with data that is already publicly available; a breach of this data would not cause significant damage to the government agency or its operations, assets, or individuals. FedRAMP defines two baselines within the Low Impact Level category, the standard Low Baseline and what is known as the LI-SaaS Baseline.

The LI-SaaS Baseline applies to Low-Impact SaaS applications that do not store personally identifiable information (PII) other than what is generally required for login credentials, such as email addresses, usernames, and passwords. The LI-SaaS Baseline has fewer security controls that require testing and verification than the standard Low Baseline, and the required security documentation is consolidated.

FedRAMP Moderate Impact Level

This is the most common impact level, accounting for about 80% of CSOs that attain FedRAMP authorization. It applies to CSOs being used for data that is largely not available for public consumption, such as PII. If Moderate Impact data is breached, the agency’s operations, assets, or individuals would suffer serious adverse effects, such as operational damage, financial loss, or individual harm (though not physical harm or death).

FedRAMP High Impact Level

The FedRAMP High Impact Level, which was released in 2016, applies to CSOs being used by agencies that handle the most highly sensitive unclassified government data, such as law enforcement, emergency services, financial systems, and healthcare systems. A data breach could have catastrophic results, including loss of human life and economic crises. FedRAMP High systems must comply with 421 controls and reduce the probability of human error as much as possible by automating as many processes as possible.

When pursuing FedRAMP authorization, cloud service providers must ensure that they choose the correct security impact level for their CSOs. For example, cloud service providers whose CSOs qualify for standard Low Baseline or LI-SaaS would not decide to pursue a JAB P-ATO, which is more appropriate for CSOs that are Moderate and High Impact.

The cybersecurity experts at Continuum GRC have deep knowledge of the cybersecurity field, are continually monitoring the latest information security threats, and are committed to protecting your organization from security breaches. Continuum GRC offers full-service and in-house risk assessment and risk management subscriptions, and we help companies all around the world sustain proactive cybersecurity programs.

Continuum GRC is proactive cybersecurity®. Call 1-888-896-6207 to discuss your organization’s cybersecurity needs and find out how we can help your organization protect its systems and ensure compliance.

Your guide to the SOC 2 Trust Services Criteria (formerly the Trust Services Principles)

Outsourcing IT services to service organizations has become a normal part of doing business, even for small companies. However, there are risks to using service providers, and these continue to evolve and change. In this dynamic environment, the American Institute of Certified Public Accountants (AICPA) made some changes to the SOC 2 Trust Services Criteria in April 2017, effective for all SOC 2 attestations with period ends after December 15, 2018.

If your company is issuing an SOC 2 attestation this year and moving forward, you must map your controls to the new SOC 2 Trust Services Criteria requirements.

The SOC 2 Trust Services Principles are now the Trust Services Criteria

AICPA has renamed what used to be called the Trust Services Principles, or the Trust Services Principles and Criteria. They are now known as the Trust Services Criteria. Additionally, the five principles that comprise the criteria are now called the Trust Services Categories.

What are the five criteria categories?

• Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to meet its objectives.
• Information and systems are available for operation and use to meet the entity’s objectives.
• Processing integrity. System processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives.
• Information designated as confidential is protected to meet the entity’s objectives.
• Personal information is collected, used, retained, disclosed, and disposed to meet the entity’s objectives.

Security is the only Trust Services Criteria category that organizations are required to include in their SOC 2 attestations. Organizations can attest to controls in the security category only or pair it with any or all of the other categories.

Integration with the 2013 COSO Framework

To better address cybersecurity risks and expand the assessment environment, the SOC 2 Trust Services Criteria have been integrated with the 2013 COSO Framework. Developed by the Committee of Sponsoring Organizations of the Treadway Commission, the framework was designed so that publicly traded companies could assess and report on their internal controls. This integration was the driving force behind renaming the SOC 2 Trust Services Criteria, as the old nomenclature would have caused confusion with the terms used in the 2013 COSO Framework.

The 2013 COSO Framework contains 17 principles, which are grouped under five internal control classifications:

• Communication and Information
• Control Environment
• Monitoring Activities
• Risk Assessment
• Control Activities

If your organization has issued an SOC 2 report previously, you will likely have to restructure your controls to comply with the new integration.

Additionally, service organizations will have to include the “points of focus” required by COSO, which are new to SOC 2 attestations. Each Trust Services Criteria category now has several points of focus that detail the features that should be included in the design, implementation, and operation of the control related to that criterion. Not all points of focus will apply to every organization.

Which Trust Services Criteria categories apply to your company?

The first step to issuing an SOC 2 attestation is determining which Trust Services Criteria categories to include. All of them may be applicable to your service organization, or perhaps only security will be relevant. Make sure to get advice from SOC 2 experts such as the professional SOC 2 auditors at Continuum GRC.

The cybersecurity experts at Continuum GRC have deep knowledge of the cybersecurity field, are continually monitoring the latest information security threats, and are committed to protecting your organization from security breaches. Continuum GRC offers full-service and in-house risk assessment and risk management subscriptions, and we help companies all around the world sustain proactive cybersecurity programs.

Continuum GRC is proactive cybersecurity®. Call 1-888-896-6207 to discuss your organization’s cybersecurity needs and find out how we can help your organization protect its systems and ensure compliance.

Advice for writing a successful FedRAMP SSP

A FedRAMP SSP (System Security Plan) is the bedrock of a FedRAMP assessment and the primary document of the security package in which a cloud service provider (CSP) details their system architecture, data flows and authorization boundaries, and all security controls and their implementation.

Keep in mind that to prevent conflicts of interest, 3PAO’s are prohibited by regulation from helping a CSP put together a FedRAMP SSP and also conducting that CSP’s FedRAMP assessment.

A FedRAMP SSP is a highly detailed document that must be readable, relevant, consistent, and complete. Even tiny mistakes can cause lengthy delays in the FedRAMP certification process. Here are some tips for writing a successful FedRAMP SSP.

Allocate sufficient time and resources to writing your FedRAMP SSP

Expect your FedRAMP SSP to be several hundred pages long. Putting together an SSP is never an overnight project, and it’s rarely a one-person job. Organizations generally require the input of several subject matter experts with deep technical knowledge of the systems they are documenting, as well as NIST and FedRAMP security controls.

Make sure the FedRAMP SSP is clear, concise, consistent, and complete

Although an SSP is a group project, it shouldn’t “look” like one when it is finished. FedRAMP PMO’s don’t expect System Security Plans to read like Pulitzer Prize-worthy literature, but they do expect that CSP’s to turn in a logically organized document that describes systems and controls clearly and completely, and that is not riddled with spelling and grammar errors. When reviewing an SSP, a FedRAMP PMO looks for the 4 C’s:

• Do not write meandering, convoluted, or overly long descriptions. Avoid the use of passive voice, as it could cause confusion. Do not include text that is not directly relevant to the specific control being described.
• Describe each system and control completely, but use as few words as possible. Make each word count.
• All system names and abbreviations, hardware and software elements, and citations referenced in the SSP should be referenced in exactly the same way throughout the entire document. The presentation style and level of detail should also be consistent throughout.
• Use the correct FedRAMP SSP template, and do not modify or remove sections. However, sections can be added if necessary. Address all required controls. If a control has multiple requirements, you must address all of them. If a control is inherited or does not apply, use a risk-based justification to explain why. You must describe how each control is addressed in your system; you cannot simply copy/paste or rephrase the control requirements.

Identify all people and places relevant to your controls

All people who are responsible for implementing/enforcing a security control must be identified, by role. All roles defined for a control should also be included in the SSP’s Roles and Privileges table.

The SSP must also describe all possible places where a control is implemented; for example:

• Access for both privileged and non-privileged users
• Access control, audit logging, maintenance, flaw remediation, and configuration management for all platforms
• Physical controls at all facilities

Be sure to select the correct Implementation Status for each control

A common SSP error is checking the wrong Implementation Status; for example, a control is marked Planned but does not identify a planned date. FedRAMP offers the following general guidance:

• If all or part of the control is an alternative implementation, check both “Partially Implemented” and “Alternative Implementation.”
• If all or part of the control is planned, check both “Partially Implemented” and “Planned.”
• If selecting a status of Planned, Alternative Implementation, and/or Not Applicable, clearly explain the aspects of the control that are Planned, Alternative, and/or Not Applicable in the implementation description.
• If the control is solely a customer responsibility, and the CSP has no responsibility for the implementation of the control, check “Implemented,” along with the appropriate customer-related control origination.

Use an automation solution such as Continuum GRC’s ITAM

Traditionally, creating a FedRAMP SSP has been an arduous, manual, and chaotic process involving dozens of text documents and spreadsheets. Updating and maintaining it over time was extremely difficult and prone to error, and it wasn’t integrated with any of the technologies 3PAO’s use to carry out FedRAMP assessments.

Now, CSP’s have access to automation solutions, such as the IT Audit Machine (ITAM) FedRAMP SSP module from Continuum GRC. ITAM is a cloud-based solution that uses pre-loaded, drag-and-drop modules to walk CSP’s through the process of preparing their SSP, ensuring completeness and accuracy. CSP’s not only save time and money upfront, while preparing their SSP, but later on, when they are ready to work with their 3PAO.

The cybersecurity experts at Continuum GRC have deep knowledge of the cybersecurity field, are continually monitoring the latest information security threats, and are committed to protecting your organization from security breaches. Continuum GRC offers full-service and in-house risk assessment and risk management subscriptions, and we help companies all around the world sustain proactive cybersecurity programs.

FedRAMP Mindset for SSP Development

FedRAMP authorization requires submitting a System Security Plan (SSP). This is a clear but detailed outline of how a cloud service provider ensures security across the organization. This is the most important document when seeking FedRAMP authorization, and it needs to be thorough with a clear picture of system security.

Going in, know that the document will likely be several hundred pages long and require the expertise and input of several people. Give your group plenty of time to create it, but ensure that the language is unfussy. Use clear terms in describing security controls, both internal and external. Be conscious of detail, because leaving something out or calling a piece of equipment by the wrong name may slow the process

Document Requirement & Acceptance Criteria

Outlining your CSP’s security posture and plan requires clear documentation (and lots of it) for a successful, delay-free submission. These documents for the FedRAMP assessment will provide a thorough picture and show that your organization meets FedRAMP security requirements at every step.

Among the dozen-plus documents you will need is one detailing your CSP’s information security policies and procedures, your contingency plan and incident response plan, a separation of duties matrix, and a continuous monitoring strategy.

Ensure that each of these documents contains clear and straightforward descriptions of each part of your security program, both internal and external. Equipment and systems must be properly identified, as well as the key players involved.

Improper or missing documentation will greatly slow down the process. 

Importance of SSP to a FedRAMP Assessment?

An appropriate Security System Plan is absolutely essential to achieve a FedRAMP assessment. Being able to clearly demonstrate that your CSP addresses the many elements to assure data security and integrity in today’s hostile cyber environment is a must.

Carve out the time to create the Plan. Prepare your documentation carefully. Work regularly with your team to craft it. Set goals and deadlines for deliverables. Double-check for clunkiness in the verbiage (use fewer words whenever possible) and ensure that all technical names and details are consistent throughout the document. 

If your organization wants to partner with any federal agency, a well-crafted SSP is a critical step to achieving it. It may take anywhere from a year to 18 months to be awarded the certification. Overlooking details or sloppy presentation can greatly slow the process down. Invest the time in doing it right.

Common Challenges in Creating the SSP

Creating the SSP is a detailed process that takes time and successful collaboration with your team. Understand these common challenges before starting.

• Understanding the hundreds of security controls required for continuous monitoring (ConMon). 
• Cross-team collaboration. It’s critical that each member of the SSP team understands the expectations around cybersecurity and the increased vigilance needed for compliance.
• The right tools. All scanning tools that are needed for Continuous Monitoring must comply with federal regulations.
• Implementing and maintaining monthly scans and related assets. A thorough monthly scan to identify any vulnerabilities is a must.
• Managing Plan of Action & Milestones (POA & M). This is a monthly inventory of active vulnerabilities and pathways to remedy them. This can be a tedious process.

Conclusion

The System Security Plan is an opportunity to do a deep dive into your cloud infrastructure to spot potential threats and vulnerabilities and get ahead of them. More importantly, this process is essential for working with any federal agency. Being able to demonstrate your ongoing compliance with important security protocols around sensitive data boosts trust and confidence among all clients.

There are a lot of moving parts to the SSP, some of which must be done on your end, but some that Continuum GRC can help you with. We offer a variety of risk management and compliance solutions to establish a more robust security plan and make putting the document together simpler.

Continuum GRC is proactive cybersecurity®. Call 1-888-896-6207 to discuss your organization’s cybersecurity needs and find out how we can help your organization protect its systems and ensure compliance.