Security Obscurity-8.19_CloudSec? That’s Not Our Responsibility
*Note: This article was originally published by the author on August 4, 2019.
In this second installment of Security Obscurity, I’ll take a quick peek behind the curtain of Cloud storage and attempt to explain why there appears to be some confusion surrounding Cloud Security (or CloudSec). Of course, CloudSec is a relevant topic of discussion considering the recent front-page news of the Capital One breach that compromised the credit card application data from 2005 to 2019 of roughly 100 million individuals in the US and another 6 million individuals in Canada which were stored in an Amazon Web Services (AWS) S3 bucket. Now lawmakers in the US want answers on how this happened from both Capital One and Amazon. Will this turn into a fingerpointing game as usual?
Cloud Security, or as I like to call it: “Pay us to store your files online, we promise to store them securely!”
First, we need to understand that the Data Owner retains full responsibility for the data they are entrusting to the care of the Cloud Service Provider (C-SP) Data Steward. The Data Steward, which in this case is the C-SP (e.g., AWS, Google, Microsoft), though they may claim in writing to be responsible for the security of the data as well, is not the organization that will be penalized, dragged through the ‘mud,’ and made to answer questions over what happened in the event of a major breach. Often, the uninitiated are shocked to learn this. The primary responsibility for any data rests with the Data Owner (or Cloud customer) and this is very clearly defined in the legal caveats of the SLA (otherwise known as “legalese”), Terms of Service, Privacy Statement, and ultimately within the State, Federal, and international compliance laws (i.e., EU GDPR).
However, believe it or not, confusion can sometimes exist between security teams over who is responsible for what actions within the Cloud Service Provider (C-SP) and customer construct. Though this confusion exists almost exclusively on the customer side of the house, the Service Level Agreement (SLA) should very clearly delineate which party is responsible for which security actions. For instance, who encrypts the data once it is uploaded into a Cloud storage bucket, container, or what have you? Normally this is a function of the C-SP but that doesn’t preclude a customer from encrypting it prior to uploading it to the Cloud so that it is double-encrypted. Or, who is responsible for reviewing the event log activity of the Cloud? Again, most times I’ve seen it is the C-SP security team that performs this function. However, whether those logs are shared with the customer security team is another story altogether and should be delineated in the SLA.
The C-SP team performs only those security and management functions as is defined in their SLA responsibilities. If the customer fails to do their part and they get hacked then too bad! It’s not the C-SP’s fault, right? This is the malformed architecture and legal construct that is putting everyone’s data at risk. What are C-SPs like Amazon, Microsoft, and Google doing to make it easier for customers to properly configure security controls so that the data they upload to the Cloud is, in fact, truly secure? Or do they even care? Are they even checking on customer storage security configuration settings? They will surely be quick to point out that it is not their responsibility, but I’d argue that you cannot simply provide a Cloud platform to store data on and then absolve yourself of any and all risk.
The Capital One case is important to illustrate as an example of security by obscurity because a lot of companies and organizations believe that if they simply upload their data to a respected C-SP vendor such as AWS, their data will be securely stored in the Cloud. Then, they sit back and are negligent in continuously monitoring and testing the security controls that are designed to protect their data or they assume that the C-SP is doing everything they’re supposed to be doing on their end. It should be well-understood that there is an inherent risk of not storing your organizational data locally on-premise and instead choosing to store it in the Cloud.
Sure, there are definite benefits to moving services and data to the Cloud, but first, you need to consider how that data will be protected not just by the C-SP but also by your organization’s security team. Yes, even if you outsource security to a Managed Security Service Provider (MSSP). Who is watching the watcher, right? Those event logs that the MSSP is sending your security team daily are probably not even being reviewed in their entirety, maybe partially. It is a major task, but it needs to be done.
It is equally important to note, however, that on-premise data servers can also be hacked resulting in a data breach just like the Cloud. This could happen if the servers are unpatched from known software vulnerabilities, 0day (unknown) vulns, phishing email attacks that compromise user login credentials, a malicious insider attack, or a compromised Web server that contains sensitive information. There is risk either way you skin it, whether storing data on-premise or in the Cloud. However, simply accepting Big Tech’s claim that
“Cloud storage is typically more reliable, scalable, and secure than traditional on-premises storage systems”
is in my humble opinion, foolish blind trust. How is your data more reliable if you lose Internet connectivity for a prolonged period of time due to a Distributed Denial of Service (DDoS) attack or a natural disaster? Answer that. Availability of data is critical to business operations. Haven’t you ever heard of not putting all of your eggs in one basket? If the Cloud is your primary storage solution, it does provide a form of data redundancy (backup) but it also represents a new avenue of security risk. If your argument is that it costs less to outsource your data management, storage, and security to the Cloud and not have to buy, maintain IT infrastructure and hire your own employees, then I understand your reasoning but I’d still argue that the Cloud isn’t that cheap, to begin with. If you stick around IT long enough, you’ll start to notice a cyclical effect as what was once fashionable will fade from popularity and then make a comeback later on. If enough companies suffer major breaches in the Cloud, you may begin to see a switch back to on-premise data storage solutions.
If moving everything to the Cloud was cheap initially, just watch how that changes over time. There is a reason that Big Tech companies have overtaken Big Oil as the richest companies on the planet. Pretty soon with “inflation” and the economic laws of supply and demand, you’ll find that you’re paying way too much for the convenience of the Cloud while opening your organization’s sensitive data up to unnecessary risk at the same time. It will be cheaper to maintain your own IT infrastructure if not now, then soon enough. Give it time. In my humble opinion, I prefer on-premise data storage primarily with encrypted full weekly and daily incremental data backups to the Cloud to ensure data redundancy. Onsite data backups should also be performed and stored in a separate location apart from the server room in case of a natural disaster such as the server room is flooded or something. But if something major happens like a ransomware attack, having something like Dropbox’s ability to restore your data back up to six months would be a huge benefit.
I believe it’s better to maintain your own data on-premise as was commonplace in the past, where you can micro-segment data where necessary, implement firewalls, encrypt data, set up Mandatory or Discretionary Access Control (MAC/DAC), and have access to the event logs without begging the C-SP. With the Cloud solution, who knows what C-SP administrators are looking at and what else is going on behind the scenes with your data? Paranoid? Perhaps. Perhaps a little paranoia is not necessarily bad when it comes to cybersecurity though.
Employing Obscurity as an Enhancement to Security
Sometimes it can make sense to use obscurity to complement security, but only after you’ve implemented security controls that are part of a robust and accepted risk management framework. Skilled attackers can still get around these obscurity hacks, but they will help against automated or scripted attacks. This could include actions such as:
- Obfuscating certain sensitive data tables within a database
- Setting up a honeypot or honeynet to fool attackers and learn their techniques
- Using an XOR scrambler to obscure chunks of TLS or other types of network traffic
- Changing the default port number of a particular server
- Removing the default administrator account or renaming it to something else
These small things may not seem like much, but they can help enhance security as part of an overall security strategy.
Just because you or the organization you work for don’t think that you have any valuable information does not mean you will not be targeted and/or attacked. Haven’t you ever heard the saying, “Curiosity killed the cat?” Curiosity is a fundamental motivation of hackers. “I wonder what’s in that computer system, server, or website… Your so-called “worthless” junk files may be a gold mine for attackers. It is not wise to underestimate the threat of compromise and the secondary and tertiary effects that will ensue following a data breach. Personal data can be leaked on the Internet, identities stolen, credit/debit card numbers stolen and used to wreck a person’s finances and credit. Businesses will take a hit to their reputation with customers and there will likely be penalties from State and/or Federal authorities, and of course, the potential for class-action lawsuits.
Don’t make the mistake of thinking that cybersecurity doesn’t matter or that obscurity can replace recommended cybersecurity best practices and controls being implemented on your systems. If you still think in 2019 that you can take the cheap way out and hope is your best course of action, I am here to tell you that hope has never been a course of action and your breach-free days are numbered. It won’t be you that is laughing if it happens when it is all said and done which is exactly why you need to plan for it now. This involves both preventive and reactive planning. Preventive planning is following a trusted risk management framework such as the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) or the NIST Cyber Security Framework (CSF), CIS Top 20 controls, COBIT, ISO 27001, among others. How you would respond to a potential data breach is known as your Incident Response (IR) plan.
If you look hard enough, it usually isn’t too difficult to find examples of security fails nearly anywhere you go. Here are a few security fails from the Internet for chuckles. Let’s hope these aren’t real examples…
That does it for this installment, until next time.