When I was studying to become a Certified Novell Instructor and then a Microsoft Certified Trainer way back in 1993, the internet was only beginning to come into being and private computer networks came in two forms: “sneakernet” and a pile of competing technologies including ArcNet, Token Ring, and some early forms of ethernet. Sneakernet was a cute term used to refer to the process of just putting the data you wanted to share or transfer on a portable storage medium (floppy disk, usually) and then walking that disk over to whatever computer you wanted to transfer it to. Considering that the local area network (LAN) technologies were sometimes slow or unreliable, sneakernet remained a reliable fallback process for transferring data. Not many of us thought about the security of data in transit to any great extent although we all understood packets structure and what “good” network traffic looked like.
Fast forward to August 9, 2006, (and I may get some who debate this) when Eric Schmidt, CEO of Google, first introduced us to the term “cloud computing” at a conference. For the first 7+ years after this newly introduced concept, cloud computing was studiously avoided as an IT tool in most large or security-conscious organizations. The thinking of the day was that it was safer to keep your data and systems in house in your own data center, on your own servers, on your own networks, and managed/oversighted by your own IT staff… or at least by the IT staff that you paid for. This thinking was, of course, at least partially accurate in that the world of cloud was still a little Wild West-y with everyone trying to get into the growing market but with not a lot of standardized security controls or normalized design principles being applied.
When IT professionals started to think about it, they realized that the idea of cloud computing had actually been evolving inside of their own data centers for some time with technologies like computing clusters, drive arrays, network traffic distribution via intelligent switches and routers, and RAID arrays; all of these technologies, when brought together and upgraded a bit, is what a good cloud environment is made of. So then the question became: is it safe to put my data, applications, and/or my infrastructure in the hands of an external entity either in whole or in part? Well, data center outsourcing was also a thing at the time of the birth of cloud computing so, again, the concept really was not (and is not) as revolutionary as it might have seemed.
The challenge that I was faced with as a security professional during the early days of cloud services was, as pointed out above, the issue of there being no security standards or best practices against which to measure the security of any cloud computing solution. I was also challenged by the fact that the people I reported to in my job at the time were all entrenched in their view that cloud equaled less security for our organization’s data. This was partially understandable since I was working in an industry that required very durable security and my employer was a major supplier in this industry so the stakes were high and jumping to a new tech like cloud computing was not going to happen without a lot of safety nets in place first.
Cloud providers all began with their own ideas of how cloud computing products should be designed and this is still somewhat true today, although these days, it is more about semantics because the core technologies used are pretty much the same. Virtual technologies are the norm in cloud computing: from virtual servers to virtual firewalls, virtual networks, etc. In addition, container-based technology is relied upon to build cloud content and functions. Cloud technologies can also be categorized in a handful of silos such as: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), Backup as a Service (BaaS), and Disaster Recovery as a Service (DRaaS).
With all of the various elements needed to build a cloud environment or cloud-based solution, and with all of these various types of cloud services, how can security standardization or general standardization of cloud services happen?
Well, there have been some evolutions on this front as well: the Cloud Security Alliance Security Framework, various ISO standards such as ISO/IEC 27701, NIST, CIS, and even some cloud providers themselves (e.g., AWS, Microsoft) have all contributed to a large tapestry of cloud security guidance, best practice, and compliance requirements.
So, where could anything go wrong, security-wise, when it comes to using cloud technologies if there is this much security guidance out there? Well, as we all probably know, not many security standards or frameworks are mandatory when it comes to complying with them. Cloud service providers realize this as well so, the more security astute cloud providers will get themselves a few security-related certifications such as C-Star, ISO/IEC 27001, and, usually the one I always try to verify with a bunch of my own fact-checking, a SOC report. The only one in this list that is dedicated to cloud security is C-Star while the others contain good security controls, there are those who think that they are sufficient for cloud security evidence but they do require additional cloud-specific security controls (something that covers container security, something about data residency requirements, etc.). Security compliance and the proper implementation of the correct set of security controls/best practices is of paramount importance in cloud solutions. It is also critical to include data privacy controls in addition to the usual set of security controls in whatever standards or frameworks that are utilized in designing your secure cloud environment.
As mentioned above, data privacy in the cloud has garnered a lot of attention as cloud services have grown. Considering that cloud solutions can literally be storing your data anywhere or transferring it anywhere, data residency is another important element to add to your security checklist. For example, if you are storing, processing, or transferring personal data belonging to residents of the EU, then you will be subject to compliance with GDPR; storing that data with a cloud provider in, say, the United States, will require that the cloud provider in the USA is also compliant with GDPR. This also applies to residents of the New York state or California or other U.S. states if you have their data and there are lots of other examples worldwide with varying requirements around that data when it is in country or in jurisdiction versus when it is outside its parent country or jurisdiction.
Privacy of personal (or health) client data can be addressed in a few ways with data residency in jurisdiction being just one way to reduce your risk profile (because violations of data privacy laws can be expensive in a few ways) but it is always critical to address both privacy and security in a very clear manner in any agreement with any third-party cloud service provider.
We had a lot of horses when I was growing up that we rode and showed; I grew in a country where winter was cold with lots of snow so the horses spent their nights, as well as all of the very cold days, inside the barn. This meant that my siblings and I had barn chores to do every morning and every night and you could not shirk your chores at any of those times because that would pile today’s chores on top of the next day’s chores. Similarly, in cloud computing, you do not want to simply take what you currently have in-house and shove it into a cloud environment or solution because then you are only moving any issues or weaknesses in your current infrastructure or solution into the cloud. Instead, cloud solutions should be treated just like any new hardware or software that you are installing – they should be subjected to security hardening based on best practices and standards such as NIST, CIS, and even the cloud provider’s guidance (e.g., AWS and Microsoft provide security best practice for their environments). First, understand the various features and options available in your cloud solution and understand how the solution will work (or hire a contractor who does) and then design your specific implementation of the cloud solution you are buying or moving to and secure it.
If your cloud provider has tools that might help you either secure or monitor the security of the cloud service or solution that you are purchasing from them, then it is probably a good idea to utilize those tools. For example, Microsoft has a Security Dashboard in their O365 product but each time I ask a client if they are using it (even when they are licensed for it), I am often met with silence and then a question asking me what it does. Another example is two-factor authentication (2FA): if your cloud provider offers it, then you should use it (and use it with an app such as Microsoft Authenticator instead of sending 2FA codes to a cell number).
Every cloud provider out there is working on security and many have learned the hard way (because of breaches and attacks) that they also need to educate their customers on security so you should not ignore the security best practice guidance from the cloud providers. If you want extra assurance, most full endpoint security providers and other security product providers are including cloud integration in their security toolsets so they can monitor, alert on, and even manage security events in your cloud product.
Like every technology, cloud services have come a long way from their early days with regards to security, integrity, and reliability but, because attackers know that cloud services house a lot of data, these services will remain high-value targets thereby making their security all the more critical. The basic principles of good due diligence and sound security practices must be applied to cloud services just like any other technology out there today. Here’s wishing you a safe and secure end of 2020 and 2021!
