Enterprise Cloud Strategy Part 2 - Experimentation

So far in our tour of Microsoft's Enterprise Cloud Strategy Book, we've discussed the 5 R's as a methodology for deciding how to "modernize" your applications.  The next section of this book discusses three common steps to a cloud migration and then focuses on the concept of experimentation.

What is experimentation in this context?

In the context of the book, the authors describe experimentation as a key step to cloud adoption.  In this step, "the engineers and others create the IT department's first cloud applications, with the objective of learning what the cloud is all about...".  The goal, of course, is to give IT the opportunity to learn about the cloud and the various aspects of building applications that live in the cloud.  One interesting aspect is how the book defines the principles of "a culture of experimentation".

My Thoughts

In my opinion, safe to fail experiments are key to the success of any projects in IT.  While I'd like to think that cloud computing does not meet the traditional definition of a complex system, the act of designing solutions in the cloud can be extremely difficult.  Moving business targets, ever-changing cloud capability landscape, and endless possible effective solutions decrease the predictability of design outcomes for similar projects.  Safe to fail experiments are key to testing out architectures that push the boundaries of the cloud platform, make use of the latest enhancements/improvements, and provide targeted feedback for lessons learned.

The second point I'd like to make is that the book makes mention of experimentation as a first step to an organization adopting the cloud.  I would argue that this is an important step not only in the initial phases of an overall roadmap, but also important for every single project that is in scope.  When I am working with my clients, I always push for a proof of concept phase as part of a cloud migration. What this allows us to do is:

• Put an appropriate amount of design work in, without having to define everything up front
• Experiment/test with multiple architectures to test for best fit
• Put focus on delivering repeatable steps via automation

This type of approach has many benefits in my mind.  Firstly, proof of concept phases can be treated as safe-to-fail experiments, allowing the delivery teams flexibility in approach and output.  Proof of concept phases are short in duration, which allow for quick iteration on target architectures.  The focus on automation not only increases the velocity of future work, it supports a more agile delivery approach.  From a business perspective, proof of concept phases help drive down uncertainty/risk in the rest of the project delivery, while increasing the accuracy of estimates around time and effort for project completion.

In conclusion, I'm a big believer of experimentation as an important aspect of project delivery, big or small.  In the context of the book, experimentation is a phase where IT is given the chance to learn more about the various aspects of the cloud and how to run applications within it.  It fits well with a "crawl,walk,run" approach, and one that can pay dividends in the long run.  My addition would be that experimentation is not only fit for the start of a cloud journey, but also fit for every project within that program.

Enterprise Cloud Strategy Part 1 - The 5 R's

Microsoft has released the 2nd edition of it's Enterprise Cloud Strategy book, and it has a ton of good content for companies looking to make the jump to cloud.  The beauty of this type of book is that it really is "cloud agnostic".  While specific examples and references are made to the Azure platform, you can use the concepts in here to plan your cloud strategy regardless of the target cloud.

I wanted to do a book review on this book, but I quickly realized that it would be a large undertaking.  There is so many core concepts discussed in this book and it would be hard to capture all of it in one post.  I've decided to write a short series on different aspects covered and my thoughts/experiences in dealing with clients in these specific areas.

Part 1, this post, will chat about the 5 R's of modernization.

When enterprises are making the move to the cloud, there is generally a business reason to do so.  The business derives values from the applications that IT hosts/maintains/builds for them, and therefore, a lot of cloud migration discussion focus on how to get applications "to the cloud".  We are not all fortunate to work with green-field cloud apps, and the 5 R's represent a set of actions one could take to migrate their apps.

The first one is retire.  This is an often overlooked option when reviewing applications for a cloud migration.  Simply put, there is always an option to mark an application for retirement and not consider it for a cloud migration.  Start working with the business to decommission the application and determine a best fit for areas of capability that are still required.

The second option is to replace.  From experience, I find that very few companies are interested in the replace option as a first step, but it is important to consider as part of the process.  With the pace of technological innovation, especially in the SaaS space, there is a good chance that the legacy application in scope might have an acceptable alternative in the marketplace.  I always suggest a short period where business SMEs and a cloud architect investigate options in the field.  One important note is that this is generally only viable when the application is non-differentiating.  Applications that act as the 'secret sauce' that separate your client from it's competition are generally not good for a pre-canned SaaS app.  Another con to this approach is integration.  Chaining SaaS applications together to deliver business value can be a difficult task.

The third option is to retain, wrap, and expand.  When considering this option, one must understand why we are moving the particular application to the cloud.  Retain/Wrap strategies are good when changes cannot be made to the application.  In my experience, I have rarely seen legacy applications written to be able to accommodate such a pattern.  Data replication patterns seem to be a best fit here, allowing you to isolate the application (and then move it) while still making the data accessible to other downstream systems.  Generally this method is used to save costs, so one must understand the ingress/egress and storage costs associated.

Expanding an application is a interesting one.  One use case I have seen is the idea of batched operation, particular for simulations.  Cloud services can be used to provide on-demand capacity to existing processes.  Many Azure batch functions work with existing HPC techniques and toolsets.

The next option is to rehost.  I always think of this as one of the "boring" approaches to cloud migrations.  In most cases, you can mimic your existing environment in the cloud, and simply move the hosting of the application there.  One thing that is often overlooked in this approach is the cost of integration with downstream systems, security systems, etc.  I've rarely found an isolated application (of value) that did not involve some degree of conversation around integration when this approach is used.  Further, integration methods that work great on-premises could have large latency/bandwidth considerations in the cloud.

The last option is reenvision.  Many companies without large development teams in-house tend to shy away from this approach.  Others have their development teams engaged in new features and not available to completely redesign the application.  While this approach may seem daunting, it often can be justified from a cost perspective.  The development time spent not only allows a legacy system to better meet the current business requirements, a modern architecture can help the application better scale/integrate/etc, allowing for easier enhancements into the future. 

In conclusion, there are pros/cons to every approach from a cloud migration perspective.  One must really understand the main business drivers for the overall cloud strategy as well as the particular application before choosing a suitable method.  Cost/Time/Resource concerns all play in to picking a successful migration strategy.

Considerations for your next centralized Identity Provider

It is no secret that cloud adoption is hitting new record rates.  The number of SaaS applications has exploded and the value they provide is so tempting that many businesses are jumping on board.  Unfortunately, this has caused some severe headaches for IT departments.  One such headache is how to manage authentication and authorization concerns on those SaaS applications in a scale-able way.

When choosing a centralized identity provider, there are a few considerations I like to look at.  More specifically, there are a few key capabilities that I like to assess as part of my decision making process.  It is important to note that a holistic identity management solution requires both the identity provider and the target application to support certain capabilities.

Consideration 1: Single Sign-on

A centralized idp wouldn't be much if it couldn't facilitate single sign-on capabilities.  What I would generally look for here is something that is capable of all the latest standards (read SAML 2.0).  Further, I am looking for some type of password vaulting technology that allows me to share passwords between multiple team members without actually giving them the password.  This is an important use case for scenarios such as corporate facebook or twitter accounts.

Consideration 2: Authorization

Not only am I looking for authentication capabilities, I also want to be able to authorize my users from a single place.  While heavily dependent on the target application, I want my idp to be able to set custom claims to help govern access to target applications from a centralized spot.  This reduces the load on IT and business super users for maintaining and managing access.  It also allows for one centralized spot for auditing of access across the enterprise.

Consideration 3: Provisioning

A lot of headway has been made in the automatic provisioning space.  In an ideal world, however, all applications would comply with the SCIM standard for cross-domain identity management.  This would make it really easy to CRUD users into those systems from a central source.  For this capability, I'd expect my idp to be flexible.  Ideally there are built-in integration with providers, but also an opportunity to add in custom integration to API endpoints to facilitate the provisioning process.  

Consideration 4: Attribute Exchange

There is generally more to configuring a target SaaS application than user data exchange.  In a lot of cases, the provisioning and authorization process will provide access to a subset of company data based on something like store locations, or departments, or some sort of hierarchy relationship.  Ideally, I can pass that information as part of some sort of attribute exchange during the provisioning of that SaaS application.  Further, I'd hope that my idp can do this for me, providing once again, a single point of management.

This capability is a little bit more pie-in-the-sky and I haven't seen too many idps meet this need.

Consideration 5: Audit and Compliance

Lastly, an idp should have really strong audit, compliance, and security components.  For example, the idp could integrate threat intelligence to help determine potentially compromised credentials.  Reporting should be able to answer compliance questions as required (who has access to what), and each login should be audited and tracked.

In short, there are a few key considerations when looking at centralized idp mechanisms.  The big names out there are making large strides in this area.  One area that needs consumer help is putting pressure on the 3rd party applications to comply with the latest industry standards such as SCIM and SAML.

Course Review: Security in a Cloud-Enabled World

Just recently released, I decided to spend some time watching "Security in a Cloud-Enabled World" on MVA.

Overall I thought it was a pretty good course, although not what I expected it to be.  The course was broken down into 2 sections, the first focusing on Microsoft's role as a Trusted cloud provider and the second being a list of roadmaps that should be considered when clients chose a cloud provider to host their solutions.

Here are a couple of points I made about the course:

1)  It is good to get validated on what I am currently doing.  When I engage as an SA on a project, I review many aspects of the roadmaps outlined in this course.  This is good validation that I am on the right path.

2)  If you want to skip several hours of boring content, just read the poster and do the quizzes. 

3)  I am not a big fan of using "user reviews" when judging how secure a cloud provider or solution is.  In the second module, many references to how users perceived the security/availability of their solutions in the cloud.  Most, as you could expect, were favorable of the cloud.  While interesting material, it has been well documented that security is a lemons market.  While I am not saying that Azure's security stance is bad, I do think that ultimately it is very difficult for customers or end users to make even an educated guess on the subject.

4)  There was an inherent lack of focus on how to do things in Azure.  While I guess that wasn't the point of the course, I think that this material needs to be covered somewhere.  In one module, the presenter talks at length about access to the administrative consoles.  Some info is provided on MFA and about how to configure subscriptions for security, but no info is presented on how to audit these admin accounts, control these admin accounts, tie these admin accounts to PAM toolsets, etc.  I think there is a lot of room for content like this.

Overall it was a good course.  It was well structured, and provides a good framework for review when designing out cloud solutions.

CCSK Study: Domain 13 - Virtualization

Notes

• Benefits of virtualization are well known but this also brings up various security concerns
• VM Guest Hardening
• Guests should still have firewall, hips, web app protection, antivirus, FIM, and log monitoring
• Can be delivered on a guest by guest basis or via hypervisor based apis
• Hypervisor Security
• Hypervisor should be hardened based on best practices
• Also consider physical security
• Inter-VM Attacks
• VM Communication can occur on the backplane and thus traditional network security is blind to that communication
• Various solutions (in-line appliances on the vswitch, for example)
• Also need to consider VM migration and how to keep track of traffic/flow
• Performance Concerns
• The resource cost of putting protection mechanism on each guest is great
• Consider options at the hypervisor level
• Operational Complexity from VM Sprawl
• large attack surface due to many requests for VM and poor management of VMs once created
• Instant-On Gaps
• VM can be secured, and then turned off.  When turned off it could then go out of date (say with security patches).  
• How do you deal with this VM when it is booted back up?
• Could use NAC to prevent network access until patches are up-to-date
• VM Encryption
• images are vulnerable to theft or modification
• images could be encrypted all the time
• performance impact
• Use DLP tools to prevent ex filtration of image
• Data Co mingling
• mixed-mode deployment (vms with different security classes hosted together)
• need to use VLANs / firewalls / etc to ensure proper isolation
• VM Data Destruction
• Need to zero disks after migration
• VM Image Tampering
• pre-configured templates may not be what you think they are
• In-Motion VM
• how do you audit/track vm's in motion?  What if they cross jurisdictional boundaries?
• Recommendations
• identify type of virtualization in use for CSP
• try to implement a zoned approach
• secure each OS via guest-tools or API based tools
• encrypt images when not in use
• use secure baselines / hardening practices
• ensure security assessment tools take into account virtualization
• employ virtual patching techniques to prevent VMs on boot up / migration

Summary

This chapter is short and sweet.  The security concerns with virtualization are vast, unfortunately the solutions have not kept pace.  Any solution at this point would be a custom type of solution that involves multiple different technologies.  Even then, it will take some time for existing providers to update their software to reliably account for virtualization technologies.  Compound this with the sheer network speed of a backplane.  Capturing and analyzing all this traffic is a large feat. 

As a client of a service provider, my recommendation would be to make a list of all the security tools you require.  Try, as much as possible, to push the cost of those recommendations onto the provider.  You probably won't like the cost of mandatory antivirus when you are paying by the IOP to run it.

CCSK Study: Domain 12 - Identity, Entitlement, & Access Management

Notes

• Concepts behind IdEA require fundamental changes when moving to cloud solutions
• Traditional deployments of servers with a standard directory service do not scale well or provide the necessary features
• Key Terms
• Identity
• The means by which an Entity can consistently and comprehensively be identified as unique
• Identifier
• the means to cryptographically assert and identity
• Entity
• user, code, org, agent, etc
• Entitlement
• the process of mapping privileges to identities and their attributes
• Reduced Sign-On
• account sync tool/process to minimize the number of credentials a user must remember
• Single Sign-On
• The ability to pass identity and attributes use secure standards such as SAML and OAuth
• Federation
• The connection of one identity repository to another
• Persona
• identity plus related environmental attributes
• IE:  Fred Smith as CEO of ACME Corp
• Attributes
• the facets of an identity
• Introduction to Identity in a Cloud Environment
• Problem similar to moving from a small town where "everyone knows your name" to a large city
• Key points to consider
• Risk calculations need to keep in mind the strength of an identity
• difference between self-assert vs CA for example
• Identity and attributes may now need to come from multiple sources
• There may be instances where a transient identity is sufficient
• There may be instances where pseudo-anonymity is desired (IE: Voting)
• Identity Architecture for the Cloud
• Cloud solutions should be able to consume assertions about identity and attributes from multiple sources
• Basic flow
• Business rules are translated into a set of entitlement rules
• An authorization engine takes assertions from multiple sources of identity and attributes and compares them to the entitlement rules
• Also factors in the "strength" of the assertion
• Authorization is granted and passed to an access management system
• Access management system governs access to key areas of the solution
• Network Layer
• One may not even be able to "see"(ping) a cloud service
• System Layer
• Entitlement rules may define the medium by which a system is accessed.  For example, RDP vs app only, etc
• Application Layer
• Functions of the application may be scaled based on the entitlement rules
• Process Layer
• Processes within the application can be scaled
• Some processes may require additional verification as specified by the entitlement rules
• Data Layer
• entitlement rules may limit access to subsets of data
• IE: Row level security
• Identity Federation
•  Defined as an interconnection of disparate Directory Services
• Technology should rest on open standards such as SAML
• Already in use as the SaaS level, but no standards exist for PaaS and IaaS
• Special considerations for the lifecycle of identities
• Think shared accounts, named accounts, priviledged accounts
• Existing systems for identity management need to be extended to support the cloud
• Provisioning and Governance of Identity and Attributes
• More than just user provisioning
• Need an appropriate set of attributes for rich risk-based decision making
• Examples
• Org Identity
• Location assertions
• Training record / compliance
• etc
• Ideally, cloud service/application should not be the master source for identity
• Some exceptions apply (Identity-as-a-Service)
• Attributes need to be linked to identity (somewhere in the chain)
• The Entitlement Process
• As per Basic Flow Above
• business requirements are used to determine the identities and attributes required to properly evaluate rules
• consider all layers in access management
• process does not stop with a launch of a cloud service.  Should consider the full identity lifecycle and periodic review
• When identities and attributes are sourced from outside the business's control, need to consider on-boarding and off-boarding of those orgs
• Considerations for enforcement points
• central/external PEP
• Embedded as part of the cloud app
• using IDaaS
• Authorization and Access Management
• Authorization layer is likely a PDP (policy decision point)
• Access management is the PEP layer
• Should use open standards such as XACML to share authorization information
• There are advantages to having the PDP implemented outside the cloud solution (and maybe within the traditional perimiter)
• logging
• central management
• access to internal resources (DS, etc)
• Architectures for Interfacing to Identity and Attribute Providers
• Hub and Spoke
• Good central control
• Can be placed on-prem
• abstracts the end-point services from the cloud provider (allowing control to dynamically add/change providers)
• Gives the org a high degree of control
• Hub can act as a cache to provide redundancy
• Free-Form
• easier to setup (from a cloud perspective)
• makes it harder to provision a user and related attributes
• makes for a more ad-hoc environment
• hard to keep multiple cloud providers in sync
• Hybrid
• Combination of the above
• Can lead to overly complex architectures
• Level of Trust with Identity and Attributes
• identities and attributes come with varied levels of trust
• traditionally, orgs have maintained their own identities and attributes 
• could potentially include many people who do not work for the org itself
• during the entitlement phase it is important to understand the attributes required but also the trust level associated with that attribute
• also a complex relationship between the strength of an attribute and the strength of the identity asserting them
• Provisioning of Accounts on Cloud Systems
• No widely used standard
• SPML - Service Provisioning Markup Language
• SCIM - Simple Cloud Identity Management
• push model may not suffice
• hard to maintain, non-standard, etc
• need to consider the whole life cycle of an identity
• disable / decommission
• Also need to consider associated data
• What about service accounts, etc, or identities for entities other than people
• Identity as a Service
• Will be covered in Domain 14
• Compliance and Audit
• PEP and PDP systems need to be configured to log according to regulatory requirements.
• Audit trails generally need to be tied to an identity
• Application Design for Identities
• bolt-on to domain-10
• Design goal should be to minimize the need for identity and attributes
• Start from the principle that identification is not required
• balance between on-the-fly account creation and a permanently identified account
• Consider attribute derivation
• Don't really need DOB, but need to know if entity is older than 18, for example
• What unique identifier will be used? (external vs internal) and management thereof
• Identity and Data Protection
• make sure all applicable laws are being adhered to if PII or SPI are stored as part of a cloud application
• Even if it is in the form of attributes on an identity
• Consumerization and the Identity Challenge
• Identity is hard with end-users and their devices
• No easy way to have a user/device enrolled in a strong authentication system
• Standards are fairly fragmented
• Identity Service Providers
• There is a fundamental level of trust issue when trusting other identity providers
• Most established identity services only deal with user verification
• Personal information is self-asserted
• Recommendations
• Read this, there is much info here
• Federation Recommendations
• Use open standards
• understand the trustworthiness of the federated party and what they verify (attributes, etc)
• Provisioning and Governance Recommendations
• all attributes should be sourced as close to the master as possible
• Cloud service/app should not be the master
• attributes should always be linked to an identity
• consider the life cycle of identities and attributes
• Entitlement Recommendations
• consider full life cycle
• All parties should be identified and rules should be clearly defined
• Entitlement rules should use the principle of least privs
• Authorization and Access Recommendations
• Use open standards (XACML, OASIS)
• Consider logging for audit/compliance
• Architecture Requirements
• Cloud providers should have PDP/PEP that is configurable
• use standard protocols
• use OATH compliance authentication
• Provisioning Recommendations
• Use open standards (SPML, SCIM)
• do not limit process to users, should include all entities
• maintenance should be done on both identity and attributes
• Identity Compliance and Audit Recommendations
• ensure that logs from PEP/PDP are available 
• log should include inputs to decision as well as the outcome
• logs containing PII or SPI will be subject to data protection legislation
• Application Design Recommendations
• minimize need for Identity and Attributes in application design
• cloud app should not be master for data
• support SSO such as SAML and OAuth
• Mutual authentication is critical
• Cloud service should authenticate user
• User should authenticate cloud service
• Data Protection Recommendations
• See domain 11 for more
• Reduce the need to store PII or SPI data
• Develop a process to deal with "Subject Access Requests"
• Identity Implementation Recommendations
• favor identity reuse rather than new enrolment
• use Risk-Based authentication techniques

Summary

This was a pretty interesting domain, one that I think generally gets glossed over.  Identity and attributes surrounding identity is the premier "user input" of our day and age.  Maybe it always was, but until you start thinking about the controls in place around this sort of stuff you don't really understand the level of "faith" than can be placed in it.

Take, for example, employee on boarding.  Potential employees send out resumes.  If you think about it, they can (and often do) write whatever they want on it.  All the information on a resume should be treated as "self-asserted" because there is no confirmation.  This even comes down to name, address, etc and scales up to things like past experience.  Now, you could take a step to verify the name and address by asking for a valid government-issued photo id.  This step allows you to not only validate identity (via the photo) but also some of the attributes (ie: name, age, address).  Validating identity becomes interesting in this case because all we have to rely on is a photo and we assume that a photo is "generally unique".  I guess you could take this one further and look at the person who is validating the photo.  Is that person trained in this sort of thing?  Is the photo in color?  Is the photo recent enough?  I might put more trust (increase the strength of the identity) if a boarder security guard validated the photo from a color passport than I would an office worker validating from a black and white photo on a plastic card.  There are obviously other measures that can be taken here, but how many offices take then?

This goes even further, to other important areas such as work history.  Unless you called to confirm employment, you only have the self-asserted data to go off of.  I know of some companies that do do checks, but most don't.  This gets even more bizarre when we get to identities on the internet.  Take, for example, linked-in.  Anyone can add experience to their profile.  In fact, they can even select the company that they worked for from a list and have their image displayed.  Does the company get a chance to review the people who have claimed that they work for them?  I wonder....

After the employee is hired, does anyone check the attributes then?  I bet not.  They probably expect honesty and rely on the policy that action will be taken against people who do not tell the truth.  Now imagine being a 3rd party that is trying to allow trust to employees of this company?  Wow, mind = blown.

Back to the course content, it will be interesting to watch the developments in this area, especially around management of cloud identities, etc.  This seems to be a place where traditional IT is falling down rapidly.  Further to this, there is a lot of "rogue business departments" provisioning their own cloud resources, independent of IT.  The lack of standards in this area is unfortunate, but hopefully we can move in the right direction.

CCSK Study: Domain 11 - Encryption and Key Management

Notes

• Encryption is necessary in certain situations, so understanding how this works in the cloud is important
• Introduction to Encryption
• Moving data to the cloud does not remove any requirements for confidentiality and data protection
• Cloud Considerations
• Data should be protected in transit, at rest, and in use
• Important in cloud deployments
• Encryption should be applied directly to unstructured content
• Key management over the data lifecycle
• Keys should be under enterprise control, not that of the cloud provider or 3rd party
• consider protection of log files or metadata that could contain sensitive information
• Use open standards with sufficient strength
• Alternatives to Encryption
• Tokenization
• Basically, public cloud service paired with private cloud/service.  Public data is tokenized which reduces the value of the data stored.  
• Data Anonymization
• Strip sensitive data before deploying to public cloud.  Could be useful for aggregate data collection
• Utilize cloud based controls
• They may be sufficient...
• Risks/Responsibilities of Data (not necessarily in the cloud)
• Accidental public disclosure
• whoops
• Accidental or malicious disclosure
• attack against
• Compelled disclosure to 3rd parties
•  obligation to respond to requests
• Government disclosure
•  either by law or court order
• Misuse of user or network profiles
• deriving sensitive information from seemingly benign traffic
• Inference misuse
• being able to draw inferences about a person's behavior or identity based on data
• Re-identification and de-anonymizing misuse
• Capturing enough information to infer the original subject
• Cryptography in Cloud Deployments
• Two Types
• Content Aware
• Basically used in DLP type solutions.  As content is being transmitted it is scanned for sensitive content.  That content is then encrypted before being sent out
• Generally works on email, etc
• Format Preserving Encryption
• encryption that preserves the format of the original content
• Better than content aware because it works over all protocols, etc
• Issues
• If data is encrypted, it might not be searchable
• Key management can be difficult if there is batch processing of sensitive data and THAT process is moved to the cloud
• Some cloud provider types will not work with "encrypted" data
• Encryption in Cloud Databases
• Consider if encryption is actually necessary
• Databases provide ACLs if that is all that is necessary to protect your data (you don't need to use encryption)
• ACLs won't work for DBAs
• You may need to comply with legal frameworks
• If you need to store data in a schema whereby you cannot control access via ACLs
• SaaS
• Good luck!
• Use Object Security if possible (ACLs on a data row/table/object)
• Store a secure hash
• Sometimes all you need is to "verify" data.  Store a hash in the cloud as opposed to the data itself
• Key Management
• Consider systems that encrypt data on the way out and decrypt on the way in
• enterprise users should have their own keys
• Use group level keys if groups are required to work on specific documents, etc
• What about the data life cycle?
• Encrypted data is easy to ensure that nobody can access it, simply lose/delete the encryption key
• consider segregation of duties around key services / process
• consider key encrypting keys (KEK)

Summary

In short, encryption is hard.  There are systems that employ data security at the file level.  This is great from a security perspective, but makes searching, etc difficult.  You need to balance this.  One idea is to use metadata for fields that you might want to search, leaving the actual data encrypted.  Another would be for an offline dump of data from the cloud for "searching" purposes.  The more metadata you store, the more you run the risk of "re-identification" issues. 

A strong understanding of the reasons why you are encrypting data is necessary here.  In some regulatory cases, you may be able to get away with enough compensating controls.  If you find yourself having a hard time with this, maybe a cloud provider for this particular solution is not the right way to go.

CCSK Study: Domain 10 - Application Security

Notes

• Cloud environments challenge many fundamental assumptions about application security
• Can be a particular challenge for applications across the layers (SaaS,PaaS,IaaS)
• Application is solely responsible for providing security
• Cannot make any assumptions about external environment
• Application can be moved at any time
• Threat landscape is increased
• In addition to traditional attack vectors we must also consider attacks from within the cloud
• Example:  You could be running your application on the same infrastructure as your competitor
• Secure SDLC
• Differences vs traditional apps
• No control over physical security
• Incompatibilities vs different providers
• Think about DR plans and migrations
• Protection across the Data lifecycle
• Data at rest is still in the cloud, so additional protections may need to be considered
• The combinations of web services in the cloud could lead to security vulnerabilities
• Maybe in the business logic domain?
• Each service now has to authenticate and secure itself
• Ability to access logs is more difficult
• Need to consider Incident Response here or even just basic troubleshooting
• Fail-over for data and data security in the cloud has to be more detailed
• Compliance related tasks can be more difficult
• It it not necessarily enough that the Service Provider is compliant, the whole process needs to be
• Organizations should have an application security assurance program
• Basically, we need to ensure we are developing applications with appropriate considerations and controls
• Goals and metrics should be defined
• Security and Privacy policies should be defined
• Consider any relevant regulations
• Appropriate hooks within SDLC to ensure security is "built-in"
• training, etc
• Perform security and privacy risk assessments to ensure appropriate requirements are defined
• Ensure appropriate verification steps are defined 
• Configuration and Change management
• Requirements (security/privacy) have been met
• formal coding practices
• physical security
• Design Review
• Review design for the common secure-design principles
• See doc or "The Security Development Lifecycle" Chapter 8
• Also see Microsoft SDLC Design phase
• Code Review
• Pick guidelines to follow
• SAFECode, CERT, ISO Standards, OWASP
• Use both DAST and SAST
• http://blogs.gartner.com/neil_macdonald/2011/01/19/static-or-dynamic-application-security-testing-both/
•  Other considerations
• Remove comments / names etc from code (it is being uploaded to a 3rd party)
• verify all input, including computer and inter-system input
• Security Testing
• Cloud architecture may prevent this step (check with vendor)
• Conduct black box penetration testing
• Use a wide scope (include remote access systems, and other related IT assets)
• Interoperability Testing
• Need to ensure that data can be exchanged between various components or applications
• Test against reference implementations 
• ie: if you are using an open standard, test that the output is valid against that standard
• Test all pairs
• Test that the transfer is "secure"
• Quantitative Improvement
• We can only improve what we can measure
• Example metrics
• % of applications and data assets in the cloud evaluated for risk classification
• costs of the application security assurance program
• estimates of past loss due to security issues
• As much as possible, we should automate security controls / testing
• Application Security Architecture in the Cloud
• Considerations for cloud applications
• Lack of control
• Cloud subscriber does not control cloud provider security policy / enforcement
• Lack of visibility
• cloud subscriber cannot see cloud security policy enforcement and controls effectiveness
• Lack of manageability
• cloud subscriber cannot manage cloud provider app security (think audit and access policies)
• Loss of governance
• no direct control of infrastructure, cloud subscriber must "trust" cloud provider to do things right
• Compliance Risk
• cloud provider now becomes a "partner" in compliance and it's policy and process now become a part of the cloud subscribers overall regulatory landscape
• Isolation failure
• New threat to application.  Isolation failure could allow competitors to access/use protected data
• Data protection
• direct control over data is relinquished and the cloud subscriber now relies on the cloud provider
• Management interfaces and access configuration
• New threat vectors as management interfaces and now accessed over the Internet
• Technical Risks and Solutions
• Identify, Entitlement, And Access Management (IdEA) is a little more complex in cloud environments
• User management lifecycle is now extended into the cloud
• typical requirements
• Understand how on-boarding / off-boarding of users will be handled
• Special cases such as service-to-service integration or cloud-to-cloud integration
• Ability to use open standards (SAML, WS-FED)
• Risk-based decisions
• User, device, code, organization, agents, geo-location, etc
• Support for internal security / compliance requirements
• Audit of user activity (especially privileged users)
• Claims-based / role-based authentication
• Manageability of permissions
• Ideally, one permission store (on-prem) uses a "mechanism" to translate and sync entitlements to various cloud providers
• may want to consider open standards such as XACML
• Compliance Building Blocks
• Infrastructure Controls
• Ex:  protecting facility from natural disasters, electrical grid failures, etc
• Auditing considerations
• Access to data center
• system admin auditing
• internal security reviews
• Application Controls
• Special considerations for regulatory frameworks
• Multiple levels of security is required
• IdEA Management for Cloud Application Security
• Traditional edge network security devices have limited effectiveness in cloud solutions
• New perimeter could be defined as data and the method by which that data is accessed
• Definition of identity should be broadened
• Includes other information such as source device
• How the source device is managed / administered
• external B2B considerations
• Authentication
• The process of asserting the users identity to a given application
• Cloud considerations
• Plan to use open standards such as SAML vs traditional "authenticate to LDAP" type mechanisms
• Plan for BYOI (Identity) whereby 3rd parties and partners can use their authentication system rather than having to maintain separate username/passwords
• Consider alternative authentication methods to username/password
• Two factor such as RSA(nsa?) Tokens, OTP over SMS (has issues, more), Smartcard, Biometrics
• Plan for risk-based authentication
• Different security steps depending on device, user, location, heuristics
• Authorization
• the process of enforcing the rules by which access is granted to resources
• Plan to use open standards to communicate entitlements
• WS-policy for defining security and management policy assertions
• WS-security for enforcing access restrictions
• WS-trust for implementing STS
• Plan to use rule-based authorization model using claims and attributes
• Attribute security
• Ensure that attributes that are shared do not reveal the users identity (Privacy issues)
• Plan for attribute complexity
• There could be multiple attribute providers
• How to handle incomplete data
• Share only the minimum amount of information required
• Ensure that access policies and entitlements policies are manageable in addition to being technically enforceable
• Claims security
• Use meaningful claims
• Ex:  verified email vs email
• Consider the type, surety, freshness and quality of the claim
• Ensure authority on claim based on context
• ex:  some applications can make certain claims
• ex:  telco can verify user phone number, others can't
• Plan for a disparate cloud landscape where multiple different authentication mechanisms need to be in place
• how do you seamlessly authentication across all cloud applications
• provide for granular control
• Audit / Compliance
• 3 questions
• What cloud resources does a user have access to?
• What cloud resources does a user actually use?
• Which access policy rules were used as a basis for a decision
• Considerations
• Build IdEA in from the beginning
• consider claims as the access mechanism
• SAPM(Shared account password management) for managing highly privileged accounts
• Use open standards (SAML)
• Cloud apps should take into consideration various token types, OAuth, API Keys, etc
• Cloud apps could be dependent on others for services such as logging or db connectivity
• Ensure modular design during development
• Can switch out IdEA module in the future if need be
• consider STRIDE during threat modeling
• Spoofing controlled via strong authentication
• Tampering controlled via digital signatures
• Repudiation controlled via digital signatures and logging
• Information Disclosure controlled via SSL, encryption
• Denial of Service controlled via Security Gateways
• Elevation of privilege controlled via authorization
• Policy Management
• access policy management is the process of specifying and maintaining access policies to resources
• Consider attributes based on identity
• caller related
• context related
• target related
• Can also consider
• General state of IT landscape
• crisis level, or emergency situation
• other decisions
• prior approvals, etc
• attributes related to the protected target resource
• QoS, throttling
• 3 typical enforcement points
• Using a Policy Enforcement Point (PEP)
• external, internal, as-a-Service
• Embedded as part of the cloud app
• using Identity-as-a-Service or Persona-aaS
• Cloud Issues
• Cloud subscriber at the mercy of enforcement points / decision making points already built into the application
• Ie: subscriber may not be able to define their own set
• Controlling access to multiple nodes / interconnected clouds
• Need to decide between identity/entitlement centric vs protected-resource centric
• Generally the PEP is the protected resource, so we need to find a way to package the information up and send it to that resource
• Identity is just one consideration
• Policies need to be in a manageable form
• Expressed in business terms and at a high enough level of abstraction that it can filter down and tools can be used to express the policy for each resource as required
• There could be many access policy providers
• How to integrate and manage them?
• Format (eg: XACML)
• Updating of PDP/PEP in a timely manner with correct(fresh) data is important
• Managing Access Policies For Cloud
• in-short, this is hard
• No real mapping exists between technical control points and business language
• Tools are required to convert Business DSL to technical controls
• Best practices
• Decide between identity-centric and resource-centric security models
• Ensure manageability of resources
• Designate clear responsibilities for policy management vs policy auditing
• Aim to have subscriber specific authorization policies
• Consider use of Policy as a service
• Consider generation/update of policy
• Aim for automatic generation tools/capabilities
• Use open standards
• Consider the use of PEP/PDPs with hooks for policy monitoring points / audits / compliance
• Application Penetration Testing for the Cloud
• Where applicable, do pen testing
• SaaS providers may not allow for this whereas PaaS and Iaas may have some support
• Use a framework
• OWASP ASVS
• OWASP Testing Guide V3
• Consider additional threats
• Isolation failure
• VM escapes
• Application Security Monitoring in the cloud
• Things to consider
• Log monitoring
• Performance Monitoring
• Monitoring for malicious use
• Monitoring for compromise
• monitoring for policy violations
• Requirements need to be defined and work needs to be done to see how the cloud provider can provide access/views to the information required
• Logs should be
• Easily parsable
• Easily readable
• Well documented
• Monitoring "ability" varies between cloud provider type
• IaaS == almost normal
• SaaS == OMG!
• Need to establish what access a cloud subscriber will have and how the cloud provider will notify/transmit information to the subscriber

Summary

This was quite a long and involved chapter.  It covered a few key points.  Once again, most of this should have factored into consideration for traditional app deployment, cloud simply adds on some complexities not yet though of.

An SDLC is key.  Building security in to the process it the best way to go.  I think that two most important tasks in any SDLC is to ensure that the team has adequate training on the threats and mitigation techniques and that there is enough work put into defining security requirements as per policy and best practices.  Additional things to consider would be things such as DR, data recovery, incident response / monitoring.

Authentication and authorization is interesting in the cloud scenario.  Ideally, you do not pass passwords to any cloud provider.  In this case, federation is key.  An extension of this is to not pass the identities either (in the traditional email / userid sense).  This is where attribute or claims based authorization comes into play.  One special case is when you start to daisy chain cloud services together.  In a traditional architecture, it is easy to take a back end service (db, web) and block any access to that except from the front end application.  As everything lives in the cloud, this becomes harder to do.  I think the discussion between identity centric and protected resource centric authorization is an interesting one, and one that I need to research further.

When I hear about application penetration testing in the cloud, I think "forget about it!".  I think the best point here is to do a paper pen test whereby you review source code, as-is documentation against the threat vectors.  I did a pen-test on a service now implementation only to find out that all controls were built client side in javascript as opposed to server side.  Discovery of this would have been easier had I just had a chance to review the code and talk to the lead developers.

As with pen-testing, monitoring is another one that where you are really up to the mercy of the cloud provider.  Security monitoring requires real tangible things such as ram/cpu/disk.  Security enforcement, even more so.  Cloud providers are in the business of delivering those resources and as such, want to charge for everything.  I think when designing a solution, we need to understand what hooks we will be provided, and how much it is going to cost to implement controls.  Sure, in an IaaS environment you could run AV, firewall, etc at the OS level.  But think of the cost of that.  It would be much better to run a majority of those services at the VM layer, but you may not have access to do that. 

CCSK Study: Domain 9 - Incident Response

Notes

• Self-Service nature of cloud may make CSPs unwilling to corporate to the extent required during an IR
• Dynamic pooling may complicate the IR process when it comes to things like forensics
• Resource pooling may cause privacy issues (for other cloud tenants)
• Technical challenge that should be addressed primarily by the provider
• Data may cross jurisdictional boundaries which can complicate the IR process
• Tasks may be prescribed by legislation
• Tasks may be prohibited by legislation
• Need legal staff on the IR team
• Eradication and recovery steps may be sped up due to the nature of how systems are provisioned in the cloud
• Some investigations can be sped up
• VMs can be moved to local resources for analysis
• VMs can be paused to preserve memory
• Different cloud architectures pose different problems to IR teams/process
• Consider the visibility and control a customer has in each cloud scenario (IaaS,PaaS,SaaS)
• Even in IaaS there are various aspects of the infrastructure that the customer does not control
• How do you get logs/data from those sources
• IR LifeCycle (NIST Version)
• Preparation
• Most important phase (regardless of cloud or not, really)
• Make sure both the physical and logical data flows are mapped out
• Establish SLA with CSP
• points of contact
• and HOW to contact (out-of-band, etc)
• incident definitions and criteria
• CSPs support (available event data, notifications, etc)
• definitions of roles and responsibilities
• IR Testing (if allowed)
• Scope of post-mortem activities
• Agree on format of data exchange
• IODEF
• RID
• Detection and Analysis
• timely detection depends on availability of the data and the ability to correctly interpret that data
• data may come from non-transparent, provider-owned infrastructure
• Key point:  Customers must make sure they have access to the relevant data
• What information should be logged
• How are the logs stored (tamper-proof) and proven that they are consistent and complete?
• Logs should take into account the dynamic nature of the logged information
• Is the time on the servers correct?
• Are you getting logs from all components and can you put that together properly?
•  Log retention settings?
• What log format is being used?
• CSS quoted but has since been abandoned
• SLA should require CSP to provide notification of any breach detection of provider-hosted infrastructure / services
• Forensic capabilities
• Still an area under research (especially for SaaS and PaaS)
• Customers should try and pick vendors that have forensic capabilities built in
• Containment, Eradication, Recovery
• Depending on deployment scenario, some tasks (such as eradication, recovery) can be made easy
• IaaS: shutdown node, restore from snapshot, etc
• SLA should include a "lessons learned" activity after the recovery
• Recommendations
• A clear understanding of how a CSP defines events vs incidents
• CSP and customer should agree on communication channels
• Customers must understand a CSPs role/support for IR
• IaaS customers should leverage virtualization offers for forensic analysis and IR
• CSP should be included in the design phase for an IR
• Requirements
• eIRP should include the approach for detecting and handling incidents involving a CSP
• SLA must guarantee support for incident handling
• Yearly testing

Summary

I think this domain touches on some key points.  Although, as a customer, you want to utilize a CSPs resources, you must understand what impact that will have in your ability to respond to a breach.  One interesting situation would involve the policy to "disclose" that a breach has occurred.  A customer and CSP may disagree on the best way to handle this and this could cause an embarrassment for one party.  This domain stresses that the SLA should be well defined and discussed, and I think is an important step that is missed during most conversations.

Capturing data from sources in the cloud can pose another problem.  One must consider the costs of first collecting the data (processing, storage, memory) and then the cost of transmitting that data to the corporate office for analysis.  What if you are also doing Security-as-a-Service?  The more abstract you get (PaaS, SaaS) will make this task even more difficult as now you are relying on the logs the provider has given you access to.

As stated in the domain, the technical solutions to the technical problems are still up in the air.  A balance needs to be found in the cost for any given solution and the benefit received from that. 

CCSK Study: Domain 8 - Data Center Operations

Notes

• "Next Generation Data Center"
• business intelligence 
• understanding of all the applications running in a DC
• Cloud Application Mission
• The industry or application mission housed within the data center
• HIPAA, PCI, etc
• Data Center Dissemination
• Cloud infrastructures that operate together but are in physically separate physical locations
• different types of applications housed by data centers require automation (to varying degrees)
• CSA Controls Matrix
• number of physical requirements based upon different standards and regulatory requirements
• Customers should request 3rd party audit of datacenter operations
• ITIL and ITSM
• New and Emerging Models
• New CSP type services based off of SETI@home
• cloud is increasingly being viewed as a commodity or as a utility
• Recommendations
• organizations building cloud data centers should incorporate management processes, practices, and software to understand and react o technology running inside the data center
• customers should ensure CSPs have adopted service management processes and practices
• understand the mission of what is running
• consider the Cloud Control Matrix

Summary

I'm not entirely sure how to take this domain.  I think it is geared more to CSPs then customers.  Basically it is saying that you should run your datacenter with appropriate policies and procedures ideally following an ITSM framework such as ITIL.  Furthermore, you should use things like automation to ensure you deliver services to your customers in an agile way.  Customers may want to check to see what processes the CSP is following and should request an independent audit.

CCSK Study - Domain 7: Traditional security, Business Continuity, & Disaster Recovery

Notes

• Traditional Security
• the measures taken to ensure the safety and material existence of data and personnel against theft, espionage, sabotage, or harm
• Physical protection is the initial step
• can render all logical controls ineffective if implemented incorrectly
• Security programs flow from well-developed series of risk assessments, vulnerability analysis, bcp/dr policies, processes, and procedures
• reviewed on a regular basis
•  Cloud service providers need to be tested regularly
• Use industry-standard guidelines such as TOGAF, SABSA, ITIL, COSO, or COBIT
• Establishing a physical security function
• Responsibility should be assigned to a manager
• Should be high-up (have power / bite)
• personnel should be trained and constantly evaluated
• As with general security, adopt a layered approach
• include both active and passive defence
• 4D's (detect, deter, delay, deny)
• Several forms of design
• Environmental design 
• Mechanical, electronic, procedural controls
• detection, response, and recovery procedures
• personnel identification, authentication, access control
• policies and procedures, training
• Many of the above are similar to what you would take in the virtual world... (it is my opinion that too many security systems were designed based on physical parameters and that is why they are somewhat easy to bypass)
• Evaluating CSP traditional physical security setup
• There may be limits in what you can do and you should balance how much of this is done with the risk of the data being stored in the environment
• Location
• Do an analysis on the location of the primary/secondary data centers
• Consider things such as seismic zones and flood planes
• Also consider human factors (political landscape, crime, etc)
• Documentation Review
• Review all the documentation that you would have had to do yourself if this project was in house
• Risk analysis, risk assessments, BCP Plans, DR Plans, Physical and environmental policies, user termination policies, contingency plans and tests, .... (lots more)
• Essentially, because this company will be handling your data/services/applications you want to make sure their policies match or exceed your own
• Eg:  Do they do background checks on all employees?, do they have technical documents of their environment? etc (there is a large list in the csa document)
• Things to check
• Are they up to date?
• Are the policies distributed to employees and accessible by them?
• Do they do training on their policies?
• Compliance with Security Standards
• ensure compliance with global security standards (ask for confirmation)
• Verify the compliance certificate
• Look for verifiable evidence of resource allocation, such as budget/manpower, to the compliance program
• verify internal audit
• Visual Walkthrough
• If you want to, make sure you know what you are doing.  There is a checklist here of things to look at
• Security Infrastructure
• Applies more when selecting a physical infrastructure provider
• Basically, you are looking for best practices in data center setup and security
• Checklist in this section (7.1.2) should be considered
• Human Resource Physical Security
• purpose is to minimize the risk of the personnel closest to the data disrupting operations and compromising the cloud
• Consider
• Roles and responsibilities are clearly defined
• Background verification and screenings are done
• Employment agreements (NDA's)
• Employment terminations
• Training (security, code of conduct, etc)
• Assessing CSP Security
• This section contains various checklists on areas to assess when selecting a CSP
• I'm not going to list them all out, read the doc
• Procedures
• Basically, are their procedures documented and made available for inspection on demand
• Things like NDAs, background checks, policies for information sharing, etc
• Security Guard Personnel
• Verify the instructions given to security personnel on what they should be checking, etc
• Environmental Security
• What protections are in place against environmental hazards (protection or detection)?
• Maintenance plans, humidity controls, physically secure locations, impact of near-by (next-door) disasters in plans, asset control policies, methods for destroying data
• Business Continuity
• Provisions should be put in place should a major outage occur 
• Financial compensation should the SLAs not be met
• Review the existence of 
• Emergency Response Team (ERT)
• Crisis Management Team
• Incident Response Team
• Restoration Priorities
• Discuss, incorporate, and quantify the RPO and RTO
• Understand the information security controls needed
• Recommendations
• There is a lot in this section and I will go over some key points.  This is another section you will want to just read
• Policy Recommendations
• "Stringent security practices should prove to be cost effective and quantified by reducing risk to personnel, revenue, reputation, and shareholder value"
•  Ensure that various policies meet or exceed the tenants current implementations
• ie: background checks, least privilege, NDAs are enforced, etc
• Transparency Recommendations
• Perform an on-site visit (preferably unannounced)
• Acquire documentation prior to visit in order to be able to conduct a mini-audit
• Human Resources Recommendations
• Ensure security team has industry certifications
• Business Continuity Recommendations
• Review BCP Plans of the CSP
• Disaster Recovery Recommendations
• plans should account for supplier(CSP) failure and have planned for the ability to switch providers
• full-site, system, disk, and file recovery should be implemented via a user-drive, self-service portal
• SLA should be properly negotiate

Summary

It is amazing how similar all of these topics are to things you would/should do in your own datacenter or organization.  There are all important points, however, to consider when migrating to the cloud.  As pointed out in the document, one must pay attention to BCP and DR issues.  There have been several notable instances where cloud service providers have "gone down" for hours at a time.  One should either protect against this via a cloud broker type tool that allows for service migration across different providers, or protect against the loss in financial terms via the SLA.

The other main point in this section is around the review of practices and documents provided by the CSP.  One of the key points here is that the CSP should be able to provide most of these documents "on-demand".  It should not come as a surprise to them that you are requesting to see their policies and procedures.  IT can be "expensive" when done properly, but that is only when you are ignoring the risk to the data and services that IT support.  As stated in the document, when done properly, security controls and IT in general can actually mitigate risk and save the company money in the event of unforeseen circumstances. 

The last point to note here is around the policies and procedures of the CSP.  Ultimately, you need to ensure they are following the same or better standards that you are following.  There has been a lot of discussion lately as to whether the cloud is "secure" or not. Some say that it is more secure than traditional IT because CSPs actually put money into the things mentioned in this document.  I think the argument is ultimately flawed.  If an IT organization was not aware of these best practices, chances are, they are not looking for it in their cloud provider... or not able to make sure that the cloud provider is doing what they say they are doing.  I guess what I am trying to say is that bad IT breeds bad IT and the problem is just worse in the cloud than it is in traditional IT that you can control.  IT organizations with strong and mature policies would probably be able to strategically use cloud resources (if they wanted to) knowing that they have processes and policies that work in-house.  They would take those lessons learned, and look for a partner (notice I didn't say CSP) that shares their same values and can provide them service at a reasonable (NOT "cheap") price.

There are quite a few good lists in this section, probably all good exam questions too.  This is going to be a section that I have to come back and review before the test.

CCSK Study - Domain 6: Interoperability and Portability

Notes

• Scenarios
• interoperability and portability allows you to scale a service across multiple disparate providers on a global scale
• could allow the easy movement of data/applications/services from one provider to another
• Not a unique concept to cloud
• Interoperability
• High level: requirement for the components of a cloud eco-system to work together
• mandates that components be replaceable by new or different components and continue to work
• Sorta like how management views employees ??? ;)
• also extends to exchange of data
• Reasons to change providers (short-list)
• Unacceptable increase in cost
• New provider provides more/better features
• Provider ceases business operations
• Provider is shutdown due to legal/disaster
• Unacceptable decrease in service quality
• Dispute between cloud customer and provider
• Remember, cloud companies are also in the business of making money!
• Lack of interoperability will lead to vendor lock-in
• Portability
• easy of ability to which application components are moved and reused elsewhere regardless of provider, platform, OS, infrastructure, location, storage, data format, or APIs
• Generally only feasible to be able to port from cloud providers in the same "class" (eg:  IaaS to IaaS)
• referring to the octant of the cloud cube
• Failure to plan for I & P Can lead to unforeseen costs
• Vendor Lock-In
• incompatibilities across different cloud infrastructure causing disruption of service
• unexpected application re-engineering
• costly data migrations or data conversion
• retrain or retooling new applications or management software
• loss of data or application security
• Moving services to the cloud is a form of outsourcing; the golden rule of outsourcing is "understand up-front and plan for how to exit the contract"[sic]
• Interoperability Recommendations
• hardware
• do not access direct hardware if you don't have to
• virtualize when you can
• physical network devices
•  try to ensure APIs have the same functionality
•  try to use network and security abstractions
• virtualization
• use open virtualization formations (OVF) when possible
• Understand and document vendor customized virtualization hooks or extensions in use
• Frameworks
• investigate CSP APIs and plan for changes
• use open and published APIs
• Storage
• use portable formats for unstructred data
• understand database system used for structured data and conversion requirements
• assess the need for encryption of data in transit
• Security
• Use SAML or WS-Security for auth controls (more portable)
• Encrypt data, understand how keys are used/stored
• Ensure that log data is portable and secured
• Ensure data can be securely deleted from the original system
• Portability Recommendations
• Understand SLA differences
• Understand different architectures
• understand portability issues which may include API, hypervisors, application logics, and other restrictions
• Understand encryption, keys, etc
• Remember to check for metadata
• Recommendations for different Cloud models
• IaaS
• use OVF
• document/eliminate provider-specific extensions
• understand the de-provisioning of VM process (secure?)
• understand the decommissioning of storage
• understand costs involved for moving data
• understand the process/governance of encryption keys
• PaaS
• use platforms with standard syntax and apis and that use open standards such as OCCI
• understand the tools available for secure data transfer/backup
• understand how base services such as monitoring and logging transfer to a new provider
• understand functionality of old provider vs new (control)
• understand impact of performance and availability 
• SaaS
• Perform regular data extractions and backups
• understand what metadata can be exported
• understand custom tools that may need to be redeveloped
• ensure backups of logs/access records are preserved for compliance reasons
• Private Cloud
• ensure interoperability between hypervisors
• use standard APIs
• Public Cloud
• ensure cloud providers use open/common interfaces
• Hybrid cloud
• ensure the ability to federate with different cloud providers to enable higher levels of scalability

Summary

I personally found this chapter hard to get through.  Portability and Interoperability are fundamental tenants of any solution, in my mind.  Being a developer, you use concepts such as abstraction to make your code more modular.  Modularity leads to code being able to be ported to different environments and allow for extensions to be built to handle specific scenarios.  I think that this chapter basically echos those fundamental tenants (over and over again).  Although it is probably better as a checklist, there are some good points that are given.  Bottom line, use open standards.  Use open technologies.  Use open APIs.  Use Industry standards.  Plan for any deviations from the above.

CCSK Study - Domain 5: Information Managemetn and Data Security

Notes

• This domain talks about the security of data in a global sense, with some emphasis on how data is secured as it moves into the cloud
• Data security begins with managing internal data
• Different cloud architectures offer different storage options
• IaaS
• Raw Storage: basically a physical drive
• Volume Storage: virtual hard drive
• Object Storage:  API access that stores data as "objects".
• Sometimes called file storage
• Content Delivery Network: Object storage which is then distributed to multiple geographically distributed nodes
• PaaS
• Database-as-a-Service
• Big-Data-as-a-Service
• Object storage with requirements such as broad distribution, heterogeneity, and currency/timeliness
• Application Storage
• Any storage that is consumable via API but does not conform to the above two
• Consumes:
• Databases
• Information may be stored in databases directly that run on IaaS
• Object/File Storage
• IaaS object storage but only accessible via PaaS APIs
• Volume Storage
• May use IaaS Volume Storage
• SaaS
• As with PaaS, wide range of storage options/consumption models
• Information Storage and Management
• data is simply entered into the service
• stored in a database (typically)
• could provide some access to PaaS APIs for mass upload type functionality
• Content/File Storage
• File stores are made available via web-based user interface
• Consumption
• Database
• Object/File Store
• Volume Storage
• Key is that the services that are consumed are only accessible via the SaaS service
• Data Dispersion
• Technique that can be used to secure data
• Data is devided into chunks and those chunks are then signed
• Chunks are distributed across multiple servers
• In order to recreate the data, an attack must be able to target all servers that contain the chunks of data
• Or attack the API that puts it all together?
• Information Management
• includes the processes and policies for both understanding how your information is used, and governing that usage
• Data Security Lifecycle
• Basically, we need to understand the "states" data can be in, the location where the data lives, and the functions/actors/controls in place to control data
• 6 phases
• Not liner, data can pass through some stages multiple times, or some stages not at all
• Create: generation of new or modification of existing content
• Store: Committing data to some sort of storage
• Use: Data is viewed, processed, etc
• Share: Information is made accessible to others
• Archive: data enter long term storage
• Destroy: data is permanently destroyed
• Location and Access
• Data can be accessed on a veriaty of end-user devices that all offer different security mechanisms
• Data can live in traditional infrastructure
• Data can live in cloud and hosting services
• Key Questions
• Who is accessing the data?
• How can the access it?
• Functions, Actors, and Controls
• We need to identify what actions we can conduct on a given datum
• Access
• Process
• Store
• An Actor performs each function in a location
• person, application, system, process
• Controls
• put in place to restrict the list of possible actions to the list of allowed actions
• Information Governance
• like information management, only different
• Includes the definition and application of
• Information Classification
• Does not need to be super granular to work (ie: differentiate regulated content from non-regulated content)
• Information Management Policies
• Defines what types of actions are allowed on a given datum
• Location and Jurisdictional Policies
• defines where data may be located
• Authorizations
• Defines who is authorized to access which types of information
• Ownership
• Custodianship
• Data Security
• This section lists out some controls to protect data
• Detecting and Preventing Migrations into the cloud
• Monitoring Access to internal repositories
• DAM: Database Access Monitoring
• FAM: File Access Monitoring
• Monitoring/Prevention of Data moving into the cloud
• URL Filtering
• Prevent access to mass upload apis, etc
• Data Loss Prevention
• Placement of network based tools must be understood and planned accordingly
• Protecting data moving to the cloud or within it
• Client/Application Encryption
• Data is encrypted before it is sent to the cloud
• Link/network encryption
• Data is encrypted in transit (SSL)
• Proxy-Based Encryption
• Legacy apps
• Not recommended
• Data is sent to a proxy-based encryption device before being sent to the cloud
• Protecting data in the cloud
• Step 1: Detection
• Content Discovery
• Need to understand the content being stored in the cloud
• Step 2: Encryption
• The different cloud architectures offer different encryption options.
• Generally: Volume encryption, object encryption
• Key management is the important issue here
• Provider-managed keys
• Client-managed keys
• Proxy-Managed keys
• Should use per-customer keys if you have to use provider managed keys
• SaaS and PaaS may not offer protections such as passpharses on the keys
• Data Loss Prevention
• Many different deployment options (endpoint, hypervisor, network, etc)
• Definition:  Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use through deep content analysis
• Database and File Activity Monitoring
• duh!
• Application Security
• Remember, most data breaches are due to poor application security
• Privacy Preserving storage
• Similar concept to VPN  is VPS or virtual private storage
• Doesn't matter if someone intercepts the data, they cannot use it / understand it
• Certs are good, but are bound to the identity of the user
• May violate some regulations if the authentication requestor knows the identity of the person accessing the information
• ABCs or attribute-based credentials
• Sorta like claims based authentication, do not need to know the user anymore, just the "rights" they have been granted
• Digital Rights Management
• encrypts content and then applies a series of rights
• For example, can play, but cannot share/copy
• Consumer DRM
• music industry! (ugh)
• emphasis on one way distribution
• Enterprise DRM
• emphasis on more complex rights, policies, and integration
• Recommendations
• Understand the cloud storage architecture in use
• chose data dispersion when available
• use the Data Security Lifecycle as a guide for building controls
• monitor internal data repositories with DAM/FAM
• Use DLP and Url filtering to track employee activity
• Use content discovery
• Encrypt data ruthlessly (my words)
• Transit, storage layer, and if possible against viewing of the CSP
• Remember that most data breaches are because of weak application security

Summary
This domain was a little bit more involved that the last one, but, once again I think focuses more on common sense than anything else.  I think the key point here is that data is hard to manage internally.  And that is okay, most corporations do not have a good way to manage that data internally, but at least the data in internal and only accessible by employees that are under contract.  Once you move to CSPs (or enable the internet...) you need to start having the right tools in place to monitor activity and usage of your data.  These includes concepts such as DAM/FAM/URL Filtering/DLP.  I personally think that the best solutions these days are those that allow data to enforce its own "security".  IE:  The data is encrypted and a client needs to be installed to un-encrypt it.  The client can then enforce policy and nobody can access the data unless the client is installed etc.  As stated in the document, this leads to expensive infrastructure to have this happen.  There are also ways around this (copy and paste for example).  To make the problem easier to tackle, create board generalizations for the data (regulated vs not-regulated) and go from there.  Understand also the concepts of key management.  Ultimately, when you do PaaS or SaaS the service on the other end will need to "understand" the data in order to be able to provide you a service.  Those risks need to be weighed out during the initial cloud discussions.

CCSK Study - Domain 4: Compliance and Audit Management

Notes

• Corporate Governance: The balance of control between stakeholders, directors and manages to provide consistent management, cohesive application of policies, and enable effective decision making.
• Enterprise Risk Management: Methods and processes (frameworks) used by organizations to balance decision making based on risks and opportunities
• Compliance and Audit Assurance: Awareness and adherence to corporate obligations
• Audit
• key component to any proper organizational governance strategy
• should be conducted independantly
• should be robustly designed
• should take into consideration the cloud
• scale and services provided
• Recommendations
• Understand that audit processes change when moving to the cloud
• Understand the contractual responsibilities of each party
• Determine how existing compliance requirements will be impacted by the use of cloud services
• Who does what?
• Be careful with PII data
• Customers and CSPs must agree on how to collect, store, and share compliance evidence
• Select auditors that are "cloud aware"
• request SSAE 16 SOC2 or ISAE 3402 Type 2 Report
• Understand how audits will be conducted
• Requirements
• Ensure a  "right to audit" clause
• Audit framework may be adapted to use 3rd party frameworks such as ISO, IEC, etc
• Ensure a "right to transparency" clause
• should include provisions for automated information such as logs, reports and pushed information such as diagrams, architectures and schematics
• mutually selected 3rd party auditors
• some agreement on common certification assurance framework (ISO,COBIT,etc)

Summary
I'm glad this was a short section!  I think that definitions used in this section are fairly common and apply to any organization, not just one using cloud.  The points made in this section seem fairly straightforward.  Basically, make sure the audit process takes into account the cloud.  Make sure that you have provisions in your contract that allow you to be compliant and force the CSP to do it's share.   All these things should be discussed up front with the CSP and the risk/benefits should be weighed if the contract is just a "click-wrapper" or non-negotiable.

CCSK Study - Domain 3: Legal Issues: Contracts and Electronic Discovery

Notes

• Legal Issues
• Many different regions and countries have numerous laws in place to protect the privacy of personal data and the security of information and computer systems.
• Most specify terms such as "Adopt reasonable technical, physical, and administrative measures in order to protect personal data from loss, misuse, or alternations"
• Examples
• OECD: Organization for economic cooperation and development
• APEC: Asia Pacific Economic Cooperation's Privacy Framework
• European Union Data Protection Directive
• Organizations should be aware of the laws they are subject to
• Even contractors of corporations may be subject to certain laws
•  HIPAA, GLBA, PCI DSS, ISO 27001, COPPA
• May not be in the form of laws, but rather contractual obligations
• Some laws may prohibit the export of data/information outside of the country
• Obviously comes into play with cloud providers
• Key point:  under many of these laws, the responsibility for protecting and securing the data typically remains with the collector or custodian of the data.  Before entering into a cloud computing arrangement, a company should evaluate it's own processes.  A company should, and in some cases is legally bound to, conduct DD of the proposed cloud service provider.
• Companies should keep in mind that CSPs are constantly updating, and they should continually monitor, test, and update their process to reflect any changes in the CSP
• Example: CYBEX
• E-Discovery Issues
• I think that although these issues were brought up during a conversation about e-discovery, they are relevant to all types of data being stored in the cloud
• ESI: Electronically stored information
• Possession, Custody, and Control
• Clients are expected to turn over all data in their control (that pertains)
• Clients do not have access to CSPs DR locations, or certain metadata that the CSP has created about a document
• Clients should have an understanding of what data is and is not avaliable
• Relevant Cloud Applications and Environment
• The cloud app may come into scope and may require a separate subpoena
• Searchability and E-discovery Tools
• Certain tools will not work with the cloud, or may be expensive to run
• Client may not have rights to search all data in the cloud
• Preservation
• Clients need to preserve the data (using all reasonable steps)
• What about SLA's?  What happens if the SLA expires before the preservation term?
• Monitoring of cloud provider?
• What about the costs of storage for preservation?
• Can the client effectively download the data in a forensically sound manner so it can be preserved off-line / near-line?
• How is data tagged or scoped for preservation in the cloud?  Does the cloud provider offer that granularity?
• Collection
• Due to CSP, collection of data may be more difficult
• Data may only be available in batches at a time
• Access and bandwidth restrictions?
• SLA may restrict the speed at which data is accessed or the manner in which it is accessed
• Cannot do bit-by-bit forensics, if required
• Client is subject to take reasonable steps to validate that its collection from its CSP is complete and accurate
• CSP may deny direct access to its hardware
• CSP may be able to produce "native production" of the data but it may not be in a usable format
• Documents should not be considered more or less admissible or credible from the cloud (provided no evidence to contradict)
• Clients should contract in provisions that they be notified and given sufficient time to fight subpoena or search warrant

Summary
This section brings up some good points about storing data in a CSP.  Although the focus here was more on the legal end, it is important to understand that these issues around the trust of data stored, how it is stored, and how it is accessible are applicable to all types of data.  The courts obviously require some degree of validation to be done that the data can be admissible in court.  Further to that, with respect to e-discovery, the courts need some degree of assurance that all the data that should have been submitted in fact was.  A subset of these issues may be important to other types of data based on contractual obligations or corporate policies.

CCSK Study - Domain 2: Governance & Enterprise Risk Management

As stated in the title, Domain 2 focuses on the issues of Governance and Enterprise Risk Management as it relates to the cloud.

Notes

• Corporate Governance
• is the set of processes, technologies, customs, policies, laws and institutions affecting the way an enterprise is directed, administered, or controlled
• 5 basic principles
• Auditing Supply Chains
• Board and Management Structure and Process
• Corporate responsibility and compliance
• Financial transparency and information disclousure
• Ownership structure and exercise of control rights
• Enterprise Risk Management
• is the process of measuring, managing and mitigating uncertainty or risk
• Multiple methods to deal with risk
• Avoidance
• Reduction
• Share / Insure
• Accept
• General goal: maximize value in line with risk appetite and strategy
• Many benefits to cloud computing, however
• Customers should view cloud service providers as supply chain security issues
• Must evaluate providers incident management, disaster recovery policies, business continuity policies...
• Companies should adopt an established risk framework
• should use metrics to measure risk management
• SCAP, CYBEX, GRC-XML
• adopt risk centric viewpoint
• framework should account for legal perspective across different jurisdictions
• Recommendations
•  Reinvest the cost savings from moving to the cloud into security
• Detailed assessments
• Application of Security Controls
• Risk assessments, verifying provider capabilities, etc
• Review security controls and vendor capabilities as part of DD
• review for sufficiency, maturity, and consistency with the user's information security management processes
• Ensure goverence processes and structures are agreed upon by both the tenant and provider
• Security departments should be engaged as part of the SLAs
• Ensure that security requirements are contractually enforceable
• Define appropriate cloud security metrics
• Really? Do these exist?
• Consider the affect of cloud limitations on audit policies and assessments
• may have to change the way audit is conducted
• remember to contract requirements in
• Risk management should include identification and valuation of assets, identificationa nd analysis of threats and vulnerabilities and their potential impact on assets, likelihoods of events/senarios, and management-approved risk levels
• Take into account vendor risk
• business sustainability, portability of data/applications,

Summary
This section essentially defines enterprise risk management and corporate governance.  In theory, all organizations should already be doing this at some level.  I think the important points here are to make sure the enterprise is aware that moving to the cloud means a loss of control over every aspect of the technical solution.  This means, in some cases, changing the way audits or testing is done to accommodate for the vendors preferences or limitations.  Further to this, you need to pay your lawyers and ensure that all requirements you have are stipulated in some form or another into the contract.  CSPs are basically an extension of the enterprise, much in the same way outsourcing is, but it basically has full control over the data you place in its possession.  I like the point about re-investing "savings" into increased security.  Ultimately, as you lose full control over an asset, you must increase your vigilance (detection tools) to ensure that your wishes as stipulated in a contract are being followed.  You can try and hide behind a contract, saying that it was the CSPs responsibility to do something, however in the courts you would have to prove that the CSP was negligent.  This may be harder than anticipated.