This week, FedRAMP published a weekly tip that addresses common mistakes made by Cloud Service Providers (CSPs).
Q: What are some common mistakes that arise when addressing Control Implementation statements?
A: There are several mistakes that CSPs encounter when drafting their Control Implementation statements. Some of those include:
Customer Responsibility
The customer specific responsibility should be addressed explicitly and consistently (e.g. addressed under a “Customer Responsibility” heading). This is so customers know exactly what their responsibilities are with regard to meeting the control requirement exclusively or in partnership with the CSP.
Control Scope
There are multiple platforms and device types in a system identified in the system inventory. At a minimum, each device type has (for instance) access controls, audit logging, and flaw remediation. Each device type may have those controls configured uniquely depending upon the location of the device within the defense-in-depth for the overall system risk management strategy. Unique configurations and implementations are addressed by device type and/or location in the security defense strategy for the system. This will normally affect the AC, IA, AU, CM, and SI control families. This means that the security control implementation details for those families and then the particular controls within the families have greater depth of detail required. Before attempting to populate the system security plan (SSP), it is recommended that one take a look at the overall system authorization boundary and all the devices and components within the boundary to understand what controls affect which devices and components. This mapping is called a Security Controls Requirements Matrix. Developing a matrix saves time in the long run when documenting the system via the SSP and it becomes easier to use a standard format for addressing controls by device or component (e.g., have a sub header within the security control implementation detail for “Cisco”, “Brocade”, “Windows”, “Linux”, and/or “Oracle”). Additionally, where applicable, each facility should be addressed including alternate, backup, and operational facilities.
Document References
Policies and procedures as well as supporting documents should be explicitly referenced (title, date and version) so it is clear which is active.
If the entire referenced document does not apply, specific sections references should be provided so the applicable sections can be located easily.
The reviewer should not have to rely solely on following the references to understand the control implementation. An overview of what the referenced document addresses and direct relevancy to the control requirement should be provided so the SSP can stand on its own. You can have a table at the end of the SSP that specifies all referenced documents, their title, date, and version. Then reference that table when a document is cited. This way you only have to maintain date and version in one place.
More Information
Read more about this week’s FedRAMP’s Tip and cues here.
