I recently had a number of consulting conversations about IT transformation and adding new Security as a Service products to companies’ existing clouds and tenancies. This is the beginning of IT transformation in many cases. A company has realized it needs to provide security to its tenants while using clouds more securely at the same time. This is a hybrid cloud. The company provides a cloud, yet uses tools from Box, Salesforce, Google, Microsoft, and the like. So, where do we start with IT transformation? With architecture that includes security.
I previously wrote about IT transformation and the need to start with a plan. Continuing the conversation, this plan needs to include security from the beginning, not as a bolt-on later in IT transformation’s lifecycle. Security can never be an afterthought; we are, after all, considering the future of an organization. We are transforming IT to handle a wider scope of products, procedures, and purposes. But this all starts with a complex question:
What are you trying to do now and in the future, and what regulatory compliance applies?
In other words, what are your requirements, and what regulatory compliance is required to meet those requirements? For example:
Requirement: Place health records within file sync and share
Regulatory Compliance: HIPAA (or any other country’s requirements for personal health information [PHI])
Another example is:
Requirement: Add in an IDS to show we take security seriously
Regulatory Compliance: Depends on the data seen today and tomorrow. Minimally, could be based on organization’s current business type:
- Medical implies HIPAA
- Sells products online implies payment card industry’s (PCI) definition of personally identifiable information (PII)
- etc.
The answer could be generic, based on the business and what the business does, and it could be specific, based on a particular business need, but it should always require looking at the future. If the requirements are not forthcoming in the detail you desire, fall back on the business type. It is okay to architect a solution to a higher level of security than is really necessary.
Let me repeat that: It is okay to architect a solution to a higher level of security than is really necessary.
No one seems to worry about security much in the rush to get product out the door. A breech happens, and then people scramble. With a good architecture, there would not be much of a scramble, but rather a plan for moving forward, etc. However, the real question is the risk to the organization that controls the security, and that arises from another question:
Who ultimately is responsible for any data and any breeches?
This is a tougher question to answer and depends entirely on the industry, current law, and visibility into any data. If, for example, you do implement an IDS cloud wide, you may end up at risk for being responsible, as your IDS looks at and inspects all packets into and out of the cloud. If a tenant does not properly encrypt this traffic, or if your IDS decrypts said traffic, it could be construed as meaning you are storing and reviewing protected PHI or PII data, or even storing said traffic unencrypted within a security subsystem, thereby putting yourself at risk and requiring that your cloud and security measures all meet the regulatory compliance for the data. This sounds like a bit of legal jargon, but it is true.If PII or PHI is in the clear, you are at risk.
To be honest, with the current batch of tools for tracing data through multi-tier scale-out applications (performance management), and tools for inspecting access to and into the applications, data is at an all-time high for being stored where it should not be.
To begin, we need a model to follow that traces the user as well as the data through any cloud, where we can then start to ask the right questions to come up with the proper architecture. Or simply ask yourself: can I see PHI, PII, or any other type of data based on regulatory compliance at any point within my current or future hybrid cloud? If that is the case, these inflection points become points where extra security should be considered.
Hybrid cloud architecture starts with knowing where you are now and coming up with a set of questions based on where you want to go. Perhaps the following graphic will help with that discussion:
The end goal is to know who did what, when, where, and how without actually storing the protected data outside its final destination to minimize risk. Perhaps we should be considering the law, and who is ultimately responsible for the data. That is, actually, the tenant.