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 cyber security experts at Continuum GRC have deep knowledge of the cyber security 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 cyber security programs.

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

Is Docker Hub hack a harbinger of increasing cyber attacks on cloud containers?

According to an official email sent to users, hackers gained access to Docker Hub, the official repository for Docker container images, “for a brief period.” However, during that “brief period,” approximately 190,000 user accounts were compromised, containing data such as usernames, hashed passwords, and Github and Bitbucket tokens for Docker autobuilds. At the time of this writing, Docker is still investigating the hack, so it is unclear how the hackers got into Docker Hub or just how “brief” their time inside the system was.

Whatever Docker’s investigation ultimately uncovers, the Docker Hub hack should be deeply concerning to everyone. As enterprises increasingly ditch on-prem infrastructure and virtual machines in favor of clouds and containers, cybercriminals are following – but container security hasn’t kept up.

Enterprises are implementing clouds, and containers, faster than they can secure them

At this juncture, no one disputes that the future is in cloud computing; even enterprises that are required by compliance mandates to run some workloads on-prem are implementing hybrid cloud infrastructures so that they can take advantage of some of the benefits of the cloud on-prem. The RightScale 2019 State of the Cloud Report found that 94% of enterprises use cloud computing, with 58% running hybrid clouds (up from only 51% the year before), and 85% running multi-cloud environments.

The popular DevOps philosophy, which (among other things) encourages enterprises to automate as many IT processes as possible, has fueled the race to the cloud. It’s also prompted organizations to shift from virtual machines to more lightweight, portable, and flexible containers. Docker containers are by far the most popular; the RightScale survey found that Docker adoption increased from 49% in 2018 to 57% in 2019. Kubernetes, a container orchestration system often used alongside Docker, is also seeing strong growth, nearly doubling in popularity between 2018 and 2019.

Organizations’ appetite for hybrid clouds, multi-clouds, and containers is so ravenous that Google centered its recent Next ’19 conference around the launch of Google Anthos, a hybrid/multi-cloud management platform built atop Google Kubernetes Engine.

Unfortunately, the Docker Hub hack may end up being the fly in the cloud container soup.

Cloud container security lagging behind implementation

While organizations certainly reap a world of benefits by migrating to the cloud and using containers instead of VM’s, cloud security is quite different from the on-prem security many enterprise personnel are accustomed to. Because of all their moving parts, hybrid and multi-cloud environments are notoriously difficult to secure. Respondents to the RightScale survey reported that their organizations are implementing cloud strategies faster than they can keep up.

Cybersecurity professionals are also fretting about container security. Sixty percent of respondents to a Tripwire survey reported that their organizations experienced at least one container security incident in the past year, and a whopping 94% are concerned about container security in their organizations.

Docker Hub hack could have far-reaching implications

Even though the Docker Hub hack appears to have impacted only about 5% of the company’s customer base, the potential implications are far-reaching. Many very large companies, including software development companies and other IT service providers, use Docker containers. The stolen Github and Bitbucket tokens can be used to access those companies’ private code repositories and inject malware into critical software auto-built by Docker, setting the stage for multiple hacks of the original target company and possibly their customers.

The cyber security experts at Continuum GRC have deep knowledge of the cyber security 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 cyber security programs.

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

Hackers Can Use DICOM Bug to Hide Malware in Medical Images

 DICOM bug enables hackers to insert fully functioning executable code into medical images

A newly discovered design flaw in DICOM, a three-decade-old medical imaging standard, could be used to deliver malware inside what appears to be an innocuous image file, a researcher from Cylera has discovered. Because the malware would not alter the protected health information (PHI) contained in the image file, it would bypass automated malware detection systems.

What is DICOM?

Originally developed by the National Electrical Manufacturers Association (NEMA) and the American College of Radiology (ACR), DICOM is an international standard protocol for the management and transmission of medical images and related data, such as MRIs and CT scans. It was created to enable healthcare providers to store and easily share medical images and related patient data digitally, eliminating both hardware incompatibility issues and the need for physical films.

Today, DICOM has become the de facto standard for CT and MRI images throughout the healthcare industry. Most medical imaging equipment supports DICOM standards, along with specialized workstations that analyze scan results, and phones and tablets that can be used to view diagnostic information.

The DICOM bug

The DICOM bug is found in the Preamble, a 128-byte section at the beginning of a file that facilitates access to the images and metadata within a DICOM image. The Preamble is used to enable compatibility with image viewers that do not support DICOM but do support common web image formats, such as JPG or TIFF.

It’s important to note that this is not a design flaw per se but an inherent feature of the DICOM file format, meant to facilitate compatibility. By modifying the Preamble, third parties can “trick” these image viewers into thinking a DICOM file is actually one of their supported formats, so that a healthcare provider could view an MRI file using their phone or tablet’s image viewer. Problem is, there are no structural requirements for the data that can be inserted into a DICOM file’s Preamble; any sequence, so long as it is 128 or fewer bytes, can be used while still maintaining compliance with the DICOM standard.

This allows hackers to do two things:

1. Insert headers that make the DICOM image appear to be an executable, or some other file format.
2. Write an executable file that is 128 bytes or less and hide it within a DICOM preamble; therefore, instead of having a DICOM file “pretend” to be another image format, an executable “pretends” to be a DICOM file.

In either case, the original PHI contained in the image’s metadata is preserved, and a hidden executable will not give itself away with an “.exe” extension. If an unsuspecting provider were to be sent an executable file disguised as a DICOM, they would see the correct file extension, and upon opening it, the correct metadata. They would have no reason at all to suspect that anything was wrong.

DICOM bug takes advantage of HIPAA regulations

The scenario gets even worse when considering that in healthcare settings, most anti-virus/anti-malware solutions are configured to ignore files that contain PHI – because of HIPAA regulations. Even if the malware were discovered, security response teams would face a quandary, again because of HIPAA. The malware and the file’s PHI would be welded together. The file couldn’t be knowingly deleted because it contains PHI. If it is accidentally deleted, the PHI could be destroyed.

This makes the DICOM bug, which the researcher who discovered it has dubbed PE/DICOM, “the first vulnerability whose technical potency is derived from a regulatory environment in addition to a software design flaw.”

DICOM bug discovered amidst increasingly sophisticated attacks on healthcare IT systems

Unfortunately, it’s not possible for any single vendor to issue a patch for this, nor are there any remedial actions that can be applied to all systems that support DICOM. The only way to fix the DICOM bug will be for the standard to be rewritten to impose standards on the content of the Preamble. Doing so while maintaining the standard’s purpose – to facilitate compatibility – is going to be a challenge, to say the least.

The DICOM bug has emerged amidst increasingly sophisticated and destructive attacks on healthcare IT systems. While it is the first vulnerability that takes advantage not just of a technical design flaw, but the regulatory environment governing an industry, it probably won’t be the last. This is why it’s crucial for healthcare organizations to practice proactive cybersecurity and actively defend themselves against not just today’s attacks but also tomorrow’s.

The cyber security experts at Continuum GRC have deep knowledge of the cyber security 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 cyber security programs.

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