This blog provides an overview of how the FedRAMP process fails to mold the Cloud Assessments in accordance with NIST's guidance.
Cloud Computing is unique and like other technologies, have a set of unique characteristics that are not typically addressed by the NIST 800-53 checklist, at the architectural and engineering level. The NIST 800-53 states as follows:
From the excerpt above, is important to emphasize the following:
This means that security controls and control enhancements focus on the fundamental safeguards and countermeasures necessary to protect information during processing, while in storage, and during transmission. Therefore, it is beyond the scope of this publication to provide guidance on the application of security controls to specific technologies, environments of operation, communities of interest, or missions/business functions.
Each cloud model has it's own set of risks at the architecture level. Cloud computing leverages Virtualization Technology, and this leads to a number of concerns that aren't typical of a non-cloud network environment. The concerns attached to the various models, include but are not limited to, the following:
||Like any technology, there's a lot of risks associated with the underlying virtualization technology used by IaaS. Some of the concerns are, but are not limited to, the following:
- Underlying Technology Type and Version- is it using the latest one? If not, how long will the vendor support the underlying version?
- Underlying Technology Hardening - are the security baselines for hardening the system fully documented? How has the underlying technology being hardened to prevent v-lan hopping or data leakage?
- Responsible Party - Who is the responsible party for maintenance, patching, and security hardening?
||Grasping the differences between the various deployment models (i.e., public, private, community, and hybrid) is important, as each has it's unique risks. Some of the concerns are, but are not limited to:
- VM isolation - How are consumer VM's isolated from each other?
- Workload Isolation- How is each tenant's environments isolated from each other?
- Network Zone (i.e., DMZ, PROD, Staging, Dev/Test, Storage) - Are the zones segmented on a single server through v-lans or does each zone have a dedicated physical server? .
- Security Protection Differences (HYBRID Model) - How will the various deployment models address data flow security risks?
- Application Programming Interface (API)- What type of API's will be supported? How are API's secured? What versions of API's are allowed?
- Compliance Requirements- Do the underlying environment (i.e., IaaS, PaaS) address compliance requirements for the sector (i.e., Government, Finance, Health) leveraging the services?
- Resource Updates- How will the resources be updated when they are no longer supported by the vendor? In the event a resource is outdated, but still required by the consumer, how will the resource be segmented to limit the impact of an incident?
||Cloud Models can have multiple cloud actors, those introducing a set of unique risks to an organization. Understanding who is responsible for each individual model and what is being offered as part of each model is essential. Some of the concerns are, but are not limited to:
- Security Responsibility - Who is responsible for the underlying infrastructure (i.e.,IF PaaS, SaaS)? Are the underlying infrastructures compliant with FedRAMP requirements?
- Defense In-depth Hardening- Who is responsible for hardening the various OSI Layers?
- Supply Chain - Who developed and maintains the underlying applications? Is it owned and sponsored by other governments?
- Open Source Applications - Are open source apps vetted prior to use? Have the organization made modifications and documented them? How are security vulnerabilities identified? How often are Open Source tools updated to address security vulnerabilities?
- Incident Response- How is incident response handled within each individual model? How will the consumer be notified of an incident at the lower layers (i.e, IaaS, PaaS) models? If SaaS using a 3rd Party PaaS, who will have access to forensic evidence? How can the consumer gain access to forensic evidence IF deemed necessary?
- Data Sanitization- How will data sanitization be handled? Does the SaaS vendor relies a 3rd Party to sanitize the PaaS environment?
- Data Segmentation- How is data for each tenant segmented? What mechanisms are in place to ensure there's no data leakage between segments?
- Configuration Management- How are configuration changes managed on the underlying environments (i.e, IaaS, PaaS) ? How do they impact the consumer (i.e, PaaS, SaaS)?
||Grasping the different entry points to each cloud model (i.e., IaaS, PaaS, SaaS, API-based) is key to identify risks associated with the different types of service models utilized. The service model interfaces can lead to the creation of different attack surfaces. Some of the concerns are, but are not limited to:
- Customer's Access Interface - Do each customer have it's own interface? How is access managed for each individual layer?
- Customer's Management- How are customer accounts, open/close/terminate accounts, manage user profiles, manage customer relationships by providing points-of-contact and resolving customer issues and problems handled?
- Inventory Management - Who's responsible for maintaining the inventory for each tenant (i.e., IaaS, PaaS)?
- Accounting and Billing- Who is responsible for managing customer billing information, send billing statements, process received payments, track invoices? How is it track per consumer?
- Reporting and Auditing- For each layer, who is responsible for reporting and auditing? In the event of an incident, can audit reports be made available to the consumer?
- Pricing and Rating- How does the provider determine prices, handle promotions and pricing rules based on a user's profile, etc. ?
- Service Level Agreement (SLA)- Does it clearly address security requirements, availability of services, Quality of Service (QoS), monitoring responsibilities, and enforcement of agreed upon policies?
|Portability and Interoperability
|| Leveraging a cloud environment should provide the ability for consumers to use their data and services across multiple cloud providers with a unified management interface.
- Portability- Can the consumer copy data objects into or out of a cloud or to use a disk for bulk data transfer?
- Interoperability - Can the consumer use their data and services across multiple cloud providers with a unified management interface?
- Migration Capabilities- Is the consumer allowed to migrate a fully-stopped virtual machine instance or a machine image from one provider to another provider, or migrate applications and services and their contents from one service provider to another?
Is important to note that portability and interoperability differs for each cloud model and might have different requirements. Understanding the differences among each cloud model is key.
NOTE: The above is not an extensive list of issues impacting the cloud. A good start is to review the document developed by NIST, Cloud Security Alliance, and ENISA. They provide a better overview on key areas of the cloud that should be address.
Interested on learning more? Contact US via our site form at https://www.cyberadeptness.com
NOTE: Due to security concerns, we limit our web content to bare bones. Please note that you will receive a response within forty-eight (48) hours or less.