The Cloud as we know it, has been around for quite some time. The originations of the Cloud first started with what is known as the “Advanced Research Projects Agency Network” (aka “ARPANET”), back in the late 1960s.
This was actually deemed to be the first kind of network topology to make specific usage of data packet switching, and to also make use of the Transmission Control Protocol/Internet Protocol (more popularly known as “TCP/IP”) which is the most widely used Internet Protocol of today.
Of course, things have grown quite rapidly since then, as evident with the Internet Bubble in the late 90s to having just about everything hosted in a Cloud based environment. In fact, with the technology that is available today, a business really does not need to have a brick and mortar office anymore.
The entire IT and Network Infrastructure can be put into the Cloud, and as long as the employees have access to what they need to do their daily job tasks, they can work from any part of the world.
There are many advantages to using a Cloud based Infrastructure of course, namely those of predictive and flexible pricing as well as on demand software services. But, the popularity of the Cloud is also gaining attention for another reason: Cybersecurity.
For example, many businesses across Corporate America are now finding it a lot easier and much more cost effective to back up all of their confidential information and data into the Cloud.
This makes sense of course, after all, if they are hit with a Cyberattack, all the IT Department has to do is create new Virtual Machines and move the information/data into them so that normal business operations can be restored in just a matter of hours.
This sure beats having what is known as on “On Premises” (aka “On Prem”), in which you are responsible for doing all of the data backups and restoration in the even of a security breach.
After all, you have now outsourced all of these tasks to the Cloud Provider and are 100% dependent upon them to do all of the daily maintenance on your Virtual Servers, which even include deploying the latest software patches and upgrades. In other words, the thinking is that this is really no longer your responsibility, it is all up to your Cloud Provider. But is this really true, though? How much is really the responsibility of the Cloud Provider and even yours???
This is an issue that has been debated for some time now and has been brought to light yet once again in which Capital One was impacted by a massive Cyberattack, with the end result being that the Personal Identifiable Information (PII) of more than one hundred million customers were impacted.
In this case, a Cyberattacker was able to gain access to the Virtual Machines that this PII was stored on, which was the Amazon Web Services.
This issue has become so hotly contested as to who is to blame in this particular incident that two politicians, U.S. senators Ron Wyden (Democrat, Oregon) and Elizabeth Warren (Democrat, Massachusetts) have requested that the FTC launch an official, investigative probe into this matter. In more technical terms, this type of Cyberattack is officially known as a “Server-Side Request Forgery”, or an “SSRF” breach.
This is where a Virtual Server (or Virtual Machine, as I have been calling them so far in this blog) an be tricked into connecting to another Virtual Server, even if there was no intention on part of the customer (in this case, Capital One) to do so. This occurs when an online application (such as a database that houses the PII) requires outside resources that allows the Cyberattacker to send specific requests from the back-end server of a vulnerable web application. If you want more detailed, technical information on this kind of Cyberattack, click on the link below:
In the case of Capital One and the Amazon Web Services (AWS), it was determined that a hosted Firewall was not configured properly, which allowed the Cyberattacker to launch the SSRF threat vector. Because of this, all sorts of PII were hijacked, specifically the following:
*Social Security numbers;
*Credit Card and Bank Account numbers;
*Dates of Birth;
In fact, SSRF attacks are nothing new, and in fact, even the other two Cloud hosting providers, Microsoft Azure and the Google Cloud, have also experienced recent breaches. But from what I understand, they have been far more publicly proactive in implementing more safeguards and protocols in order to prevent this from occurring in the future.
But apparently, the AWS was not proactive in this instance, thus, that is why they are getting fair share for the blame in this awful security breach.
My Thoughts On This
So now, the blame game starts. Long story short, the politicians thinks that the AWS should bear some of the responsibility, while the Cybersecurity crowd thinks that it is Capital One whom is squarely responsible. And believe it or not, there is even that crowd that says to forget the whole thing and move on from the lessons learned. So, what do I think about this?
Well, first and foremost, it is up to the Cloud Provider to make sure that all of the services that it offers to its customers are up to snuff and that all of the latest safeguards are in place to protect the PII that will be stored in them. After all, this is their job, and they should bear the brunt of it.
This like moving into a new apartment: It is up to the property owner to make sure that you are provided with a clean and safe place to live, but after that, it is up to you take care of it. They can only be there to provide maintenance support as they arise. This is also true of the AWS.
After Capital One started to rent out their services, it is then their responsibility to make sure that everything remains up to snuff. A Cloud Provider cannot monitor all instances of Cloud based deployments, as they would have to constantly monitor hundreds of millions of customers on a daily basis, which is an almost impossible task.
In this case, it is then up to Capital One to make sure that all of their deployments into the AWS are as safe and secure as can possibly be. Now, if they detect an anomaly that needs immediate attention, then it is their job also to notify the AWS, who from there should investigate it into it further. That then becomes their job.
So long story short, yes, I think a thorough investigation should be conducted, as in the case of all large scale Cyberattacks. If it has been discovered that the AWS did not configure something properly or deploy an item that was needed initially before Capital One started to make use of their services, then they are to blame.
But if everything was up to par beforehand, then Capital One should take the entire blame. After all, it could have been very well one of their deployed applications that was not tested properly that could have been the trigger for the improper configuration as well. In fact, this whole situation is like the example if a CIO or CISO should be immediately fired after their organization has experienced a security breach.
Yes, ultimately should be held responsible, but only after a thorough investigation has been done, and it has been determined where the evidence points to. This also brings up a very important point. When you sign up for a new Cloud account with a provider, you are often provided with what is known as a “Service Level Agreement”, or “SLA” for short that you are required to sign before you can use their services.
This is an extremely detailed contract that spells out your responsibilities as well as your Cloud Provider’s in making sure that your account is up to par with all standards. Unfortunately, these documents can be as long as 90-100 pages, so the temptation to just sign is quite strong. I know this stuff is very boring and time consuming to read it, but it is very important to do so.
If you don’t have the time to do this, give it to an attorney that you trust to review it for you. Believe me, it will be well worth the money spent, especially if you find your business to be in the same predicament as that of Capital One.