Shining a light on Public Cloud data security and governance
Cloud usage and security should go hand in glove and as consumption of cloud services grows exponentially, we risk making the same or similar mistakes that we made in the past. This time the stakes are much higher because of the scale of exposure. Back in the early days of the Internet a hacker often took over a web site and added some unflattering text or image — that was seen in those days by a relatively small number of people. In fact, there were only about 16 million Internet users or about 0.4% of the world’s population in 1995.
Since that time, developers have been happily cranking out applications behind the relative safety of their firewalls, often without fully considering or cognizant of the security profile of those applications. Today we are approaching 4 billion Internet users (51%+ of the world’s population) and the reputational and other damage inflicted by a security breach can be massive. Equifax, Yahoo, Uber, …
Not in my back yard
A recent article helps illustrate the issue of Information Supply Chain Management (ISCM). It’s unfortunate that a Twilio graphic was chosen as the article goes on to point out this issue is not with Twilio but rather with developer practices when consuming their API’s. Actually, I consider Twilio’s approach to providing secure API’s a good model for others to emulate.
The major cloud players are continuously improving the security of their platform and services and providing attestations of their security practices and regulatory compliance. Their attorneys are crafting terms of service that are increasingly providing bright demarcation lines as to where the providers responsibility ends, and the consumers of those services responsibility begins. If you think about it, it’s a lot like the disclaimers you see in a public parking garage – you can park here but we’re not responsible for theft or damage to your car.
Is your car at risk in a publicly accessible garage? Certainly, but it’s in the garage owners interest to keep your car as safe as they can so you continue to want to park in their garage – and the major Cloud players are doing just that – securing that which they are responsible for. What happens when your car leaves their garage though is another matter.
How did I get here, and do I care?
If you are using a “walled garden” instance of a SaaS application like Office 365 or Salesforce, you are relying on the security controls put in place by those providers to ensure the Confidentiality, Integrity, and Availability (CIA) of your data. However, once you extend the functionality of these applications by integrating third-party application(s) using their API’s, you are introducing additional vendors to your information supply chain.
What assurance do you have regarding the security of that third-party providers API? What are the processes in place at the third-party API provider with respect to keeping their open-source libraries patched and secure? What is their development framework? What is YOUR organizations development framework and/or best practices related to security when consuming cloud API’s?
In the case of Twilio, they appear to be proactive in securing their API’s and adhere to security best practices as demonstrated by their ISO 27001 certification. That may not be the case for all the API providers in your Information Supply Chain. The nature and sensitivity of your data coupled with regulation and compliance requirements will help define your organizations risk profile and the vetting requirements of your Information Supply Chain. This should be well understood before moving data in and out of the Cloud.
Infrastructure is Code
The virtualized nature of the cloud services makes use of scripting to operate efficiently; DevOps, Containerization, Application Development, and integrations all make use of code. Infrastructure is increasingly becoming code and that means you need to pay even more attention to your coding practices with respect to security. DevOps cuts both ways, it can speed implementation of both secure and unsecure code.
The hard coding of connection strings and/or security credentials in code discussed in the Twilio article, is certainly not a best practice and is completely avoidable. Unfortunately, is also not uncommon. This and other bad practices are being repeated in the Cloud out of habit, lack of education, and/or attention. While this may have “worked” in an on-prem environment, it poses a huge risk in a cloud environment and a significant threat to your corporate data. In the rush to take advantage of the many benefits of cloud computing, NOW is the time bring the security conversation and best practices to the table BEFORE deploying applications in the Cloud.
The Ferris Bueller connection
So, before you hand over the keys to your Ferrari (corporate data) to the parking attendant, you should do your due diligence with respect to all the parties involved in keeping your Ferrari safe both in the garage and out on the roads (API’s) where it may travel.
Ferris had a great day driving the corporate data around but found it very difficult to keep it safe (nor did he give it much thought) once it left his friends Dad’s garage (corporate data center). There is an avalanche of Cloud Services coming and not all them are created equal or demonstrate the same focus on security. Who’s driving your Ferrari and where?
Bueller? … Bueller? … anyone?