My new role at EMC is to teach people to be Virtual Data Center (VDC) and Cloud Architects. For me this is a great privilege and an incredible learning experience – and a chance to build trust in the cloud one architect at a time.
During the process the team of course developers researched hundreds if not thousands of papers, read numerous books (such as Nicholas Carr’s The Big Switch: Rewiring the World, from Edison to Google, David Linthicum’s Cloud Computing and SOA Convergence in Your Enterprise, Jeff Barr’s Host Your Web Site in the Cloud, Scott Lowe’s Mastering VMware vSphere 4, and Edward Heletky’s VMware vSphere and Virtual Infrastructure Security to name a few), tons of blogs, and reviewed websites of manufacturers and consultants too numerous to list. We also spent time reviewing the standards and emerging standards developments such as the Cloud Security Alliance (CSA), the European Network an Information SecurityAgency (ENISA), Also the great work that the National Institute of Standards and Technology (NIST) have been doing – all of which we’ve incorporated their guidance and definitions into the class.
One of the modules included in the VDC and Cloud Architect course we’ve developed includes a Governance, Regulatory, and Compliance (GRC) section that I developed focused on VDC and Cloud GRC definitions and processes. As I’ve had a chance to first research this in-depth and to teach it to over 50 people now I’ve come up with a list of what the top ’10’ tenets:
- Always OWN your information no matter where it is. This has to be the number one rule. Always own your own data. Make sure that wherever it gets created, stored, shared, etc. that if it is your company’s information asset. Good providers will put that in writing in their terms of service.
- If you don’t have good GRC today, what makes you think you will have good GRC practices in a VDC or Cloud? Seriously – does anyone think that if they go to a cloud they are all of a sudden going to have these great new policies and processes? Can you inherit new ones that the provider has that improve your standard? Sure – but how will you know that if you didn’t come up with a standard in the first place?
- Develop an information life-cycle for all information – cradle-to-grave. Information has a lifetime. Keep it too long and it gets you and your company in trouble. Either because it gets acquired by someone you don’t want to acquire it or demanded by a regulatory or legal entity that wants to get all the data they can going back forever if they can. Just like you can’t leave stacks of all printouts and correspondence around your office forever – you need to be diligent with your digital information. When it is created – set an expiration date, create an archive policy, and a purge date!
- Less (information) is more. One of the bad habits of the past couple of decades is that we develop software and databases that collect and store a lot more data than we’ll ever need. Information is a powerful tool – but it can also be a liability. Collect what you need it will save you a lot of headaches and $$$ (minimally for storing and protecting) down the road.
- Develop an Information Taxonomy. Back a few decades ago – enterprise development efforts had things called meta data dictionaries and information flow diagrams. Because a large enterprise has so many applications that not only collect new data but also reuse data collected earlier dependencies become critical for data accuracy reasons. For example when a new application is built that is customer facing – recollecting the same customer data each time they engage with your company is both frustrating for the customer as is the inherent probability of creating a nearly duplicate set of information. I said nearly duplicate for a reason – the customer may put the address in different the second time creating a second version of the data. So when another application needs it – which one is right? By creating a taxonomy you can develop a methodology for single sourcing critical data, remove redundancies, and in this day and age – manage the regulatory and legal issues related to certain types of data.
- Always know who your (data) handlers are. Let’s face it – systems in general let more and more information be seen and handled by more people. This raises the risk quotient considerably. When you leverage a cloud services provider – you need to take the time to find out their data handling procedures are. You are effectively increasing the risks and attack surfaces by extending your technology, people, and processes into the cloud. How do you mitigate this? One way is to go back again and read those terms of service. A good provider is going to say things like “our employees do not have direct access to your information nor are they allowed to engage with it without your express written permission” – when they want an affidavit attesting they are allowed to access it – they take their access to your data pretty seriously.
- Cloud Security requirements regarding information should be at least as good as internal, recommend they are better. This is much like the GRC standards in-house in #1 – but has to be said. Make sure your security standards are met by the provider and ideally their standard is higher. We’ve developed some excellent tools in the course that help determine what this should look like.
- Think about Transitivity! This one applies to both service levels and other items like 3rd parties. For service levels – always look at what each discreet service you are using has for an SLA and then think about what happens when you bundle services. For example when you combine a Virtual Machine service that is 99.95%, and a storage service that is 99.99% and a messaging service that is 0.00% – you get a combined service bundled that you can expect a 0.00% SLA. When it comes to other items of concern – make sure the provider has the same standard for their 3rd parties as they do for their employees. For example the provider uses a security contractor for their info-sec department. Do they do the same background and drug tests on the 3rd party’s as they do for their employee’s? Does the provider have the same standard as you do for your employee’s? See the transitivity issue here? Make sure the standard is as good as or better!
- Evaluate your assets in terms of Asset Value. We spend a lot of time in the class talking about this one. take the time to come up with asset valuations that are going to go into the cloud. For example come up with a quick score that rates the asset as High/Medium/Low in value. Then make a policy decision that all High value assets either need special security provisions in the cloud or they just can’t be put in the cloud for now. This process helps prioritize the start of the process for assessing the cloud for your information assets and prioritizing the candidates but it is only the beginning.
This isn’t an exhaustive list – but is a good starting point for coming up with some good practices for building trust in the cloud and assurance for Information Handling. Want to learn more – then come take our EMC Proven Professional VDC & Cloud Architect Class!