UNDERSTANDING CLOUD SECURITY: PART TWO...

Google

I thank you for your attention on the previous post where we had a look at security considerations for the three main cloud service models commonly referred to as SPI (SaaS, PaaS, IaaS). As promised here’s part two looking at other cloud implementation considerations, namely:

• Cloud deployment model: public vs. private vs community vs hybrid deployments,
• Cloud location: internal vs. external hosting or combined,

As you would expect coming from me :), I think a very important initial step (part of your risk assessment) is to classify your assets in order of criticality to your organisation. Once an understanding of the asset’s importance is gained, the organisation should determine which risks will be acceptable to their security posture in the various deployment models and hosting locations. The Cloud Security Alliance paper also  gives some useful details regarding multi-tenancy consideration. This step enables the mapping of the organisation’s security and risk requirements for the asset depending on how (deployment models) and where (locations) the services will be deployed.

As an aside, for those subject to PCI DSS compliance, please remember that the risk assessment requirement (12.1.2 if you must ask) is now part of milestone one of the risk prioritised approach v2.0 , which for the uninitiated means that it’s one of the first things you should do... There we are: immediate synergies between PCI endeavours and cloud considerations...

Once the asset has been classified and risk appetite ascertained for cloud deployment and location, the next step will be to focus on the degree of control and risk management the organisation will have for each of the cloud service models. This is because, whilst the risk assessment depends on the “where” and “how” of the assets described in the previous paragraph, it also depends on the following:

• The types of assets being managed;
• Who manages them and how (to clarify, the responsibility may be solely with the consuming organisation, solely with the cloud service provider, or shared – in all cases, the accountability for the security of the assets remains with the consuming organisation);
• Which controls are selected and why;
• What compliance & regulatory requirements apply.

Consideration should be made for risk mitigation in each of the SPI tiers (SaaS, PaaS, IaaS) and compliance and regulatory requirements should be considered (e.g. PCI DSS, FSA, HIPAA, SOX, etc.). At this stage, organisations will evaluate and assess the risk for potential cloud service models and providers. This will be a challenging undertaking, as organisations will need to ask cloud services providers to disclose their security controls and how they are implemented to the “consuming” organisation, and “consuming” organisations will need to know which controls are needed to maintain the security of their information. Lack of thoroughness at this stage can lead to detrimental outcomes.

It is therefore critical that a cloud service is classified against the cloud architecture model (see diagram in my previous post), then against the security architecture (from physical through to application layers), and then against the business, regulatory and other compliance requirements (which essentially amounts to a gap analysis).

In SaaS environments, the security controls and their scope are negotiated in the service contracts (SLAs, privacy, compliance, etc.).

PaaS service providers will be responsible for the security of the platform, whilst the “consuming” organisations will be responsible for securing the applications developed against the platform as well as developing them securely (e.g. OWASP Top 10, code reviews, etc.).

In and IaaS offering, the provider will be responsible for securing the underlying infrastructure and abstraction layers, the consuming organisation will be responsible for the security of the remainder for the stack (tip: good to look at SAS 70 Type 2/ SSAE 16 for starters)

Finally, when evaluating specific deployment options, organisations should map out the data flow between all consumers and providers (e.g. the organisation, the cloud service, customers, other nodes, etc.). Before making a final decision, it is essential to understand whether, and how, data can move in and out of the cloud in order to identify risk exposure points. (Incidentally, data flow mapping is also a PCI DSS requirement, see 1.1.2)

In addition to the previous checklist, the Cloud Security Alliance also developed guidance on the most common threatsto cloud computing which provides useful context to assist in making educated risk management decisions regarding cloud adoption strategies. The top threats are listed below:

• Abuse and nefarious use of cloud computing: affects IaaS and PaaS.
• Insecure application programming interfaces: affects IaaS, PaaS and SaaS.
• Malicious insiders: affects IaaS, PaaS and SaaS.
• Shared technology vulnerabilities: affects IaaS.
• Data loss/ leakage: affects IaaS, PaaS and SaaS.
• Account, service & traffic hijacking: affects IaaS, PaaS and SaaS.
• Unknown risk profile: affects IaaS, PaaS and SaaS.

By following a risk-based approach, organisations will understand the importance of what they are considering moving to the cloud, their risk tolerance (at least at a high level), and which combinations of deployment and service models are acceptable. They will also have a rough idea of potential exposure points for sensitive information and operations. Armed with this, organisations will also be in a position better to negotiate contracts and SLAs that are fit for purpose, no forgetting other financial implications, such as tax considerations.

I hope this post has encouraged you to read the Cloud Security Alliance paper “SecurityGuidance for Critical Areas of Focus in Cloud Computing v3.0 (November 2011)” and I leave you with one final thought: it’s all about risk... (see next post)

Until next time...

neirajones