At the end of May, Microsoft announced the launch of the Asia-Pacific Public Sector Cybersecurity Executive Council to unify policy makers from government and state agencies.
The initiative includes 15 policy makers from Singapore, Indonesia, South Korea, Malaysia, Thailand, Brunei, and the Philippines who will virtually meet every quarter (thanks COVID-19 advancements), to establish a “continuous” sharing of information on cyber threats and cybersecurity products.
With a sharp rise in ransomware and malware attacks throughout the coronavirus pandemic, SMBs and large enterprises still have to address the many security vulnerabilities that have just been made available due to shifting business models and archaic security infrastructures.
One of those vulnerabilities is cloud object storage, which depends upon the many programmers and developers to implement so that their clients, SMBs and enterprises, are protected from losing its highly sensitive data.
In strengthening cloud object storage security, we need to examine three key steps, beginning with any potential for misinformation or misinterpretation about what “cloud object storage security” is and what it isn’t.
Most importantly, cloud object storage is not synonymous with ‘cloud security’, ‘cloud storage security’, ‘storage security’, or ‘data security.’ Why do the specifics matter here?
This is a humongous market, and just adding or removing one word changes the entire meaning, messaging, and landscape, according to Extenua’s technology inventor Federico Simonetti.
“There’s millions and millions of corporations that store a lot of ‘unstructured data’—which means files and folders, rather than databases--in cloud object storage services such as Amazon S3, Microsoft Azure Blob Storage, Google Cloud Storage, or any flavor of Openstack Swift Object Storage (IBM Cloud, Oracle Cloud, etc.),” Simonetti told me.
Simonetti serves as the company’s founder and chief technology officer. Extenua is an award-winning developer of enterprise security software that simplifies and secures cloud object storage technologies, servicing Fortune 500 companies like IBM, Fujitsu, Boeing, Nokia, Sony, Toyota, US Bank, Motorola, as well as government institutions, security agencies, and thousands of small and mid-size businesses.
In my conversation with Simonetti, I had trouble understanding why this was so important to segregate from traditional cloud storage conversations.
“All of these storage services are designed for convenience, not security,” he explained. “Some of them provide some sort of basic security, but it's up to the customer to configure it and operate it properly.”
In a 2014 article by Rapid7, current market solutions have proven to be extremely dangerous and ineffective.
“Mistakes by companies in using those storage services caused 120+ billion files to be exposed, making them vulnerable and publicly accessible," Extenua's CTO explained. "And even if you configure it correctly, cloud object storage still remains insecure because the main goal is still convenience.”
And to Simonetti’s point, as I have said in every cybersecurity piece I have written--convenience will always trump privacy.
#1 - Why ‘Slicing Your Files’ Matters
So, what does ‘slicing’ your files mean?
The purpose, according to Simonetti, is to ensure that no single cloud provider has all the necessary pieces to reconstruct your original files.
“If you slice each file into smaller chunks, then you can store each chunk in a different cloud object storage; this way there’s not a single cloud provider who even has all the necessary pieces to reconstruct your original files,” he said.
In the event there is a “security incident,” all is not lost. “Even if one cloud object storage is broken into, the hacker would still not have all the chunks to rebuild any of your original files,” Simonetti explained.
And of course, the probability that two distinct cloud vendors are hacked at the same time is close to zero. As of the date of this article, no such incident has yet occurred.
Let’s take Amazon S3 buckets, for example, and the “public” status of its “buckets.”
Amazon Simple Storage Service (S3) provides the ability to store and serve static content from Amazon’s cloud. Traditionally, businesses use S3 to store server backups, company documents, web logs, and publicly visible content such as web site images and PDF documents. These files within S3 are then subsequently organized into “buckets” which are named logical containers accessible at a predictable URL.
These buckets are usually considered “public” if any user can list the contents of the bucket, and “private” if the bucket’s content can only be listed or written by certain S3 users. In other words, a public bucket will list all of its files and directories to any S3 user that asks.
Down the Rabbit ‘Hole’ of S3 Buckets
A study conducted back in May 2013 by a cybersecurity researcher at Rapid7 discovered that out of 12,328 unique buckets:
- 1,951 were public
- 10,377 were private
And 1 in 6 buckets of the 12,328 identified were left open for any user to peruse. Of the 1,951 public buckets, there were 126 billion files gathered, which proved to be practically impossible to look through every file.
However, of the 40,000 publicly visible files, many of which contained sensitive data. The takeaway from this study, Simonetti suggests, is that the current processes have proven to be “extremely dangerous and ineffective.”
“Mistakes by companies in using those storage services caused over 120 billion files to be exposed, vulnerable, and publicly accessible. And even when you configure it correctly, a cloud object storage still remains not-so-secure, because its main goal is convenience.”
According to Simonetti, had those files been chunked-up and scattered across multiple cloud-object storages from different cloud vendors, none of those 120+ billion files would have been lost or otherwise compromised.
#2 - Having a Unique Encryption Key for Each Piece
Second, it’s important to encrypt each piece with a unique encryption key that is never stored anywhere.
Traditionally, encryption keys tend to be reused, which are almost invariably stored somewhere.
“For worse, they tend to be stored somewhere, whether it is a symmetric key, or the private key of an asymmetric key-pair, they’re always stored somewhere,” Simonetti explained.
“Imagine if someone figures out how to access that key; if you used the same key or key-pair to encrypt all of your storage, the hacker now has access to all of your data with a single decryption operation. It’s pretty intuitive to understand how using distinct encryption keys for every file chunk, and - more importantly - never storing said keys anywhere, can greatly increase your security.”
The importance of having a unique encryption key, rather than reusing the same key over again, is that with the right proprietary technology, equivalent to what Extenua utilizes, is that these keys are never stored anywhere.
“The beauty of this encryption key management system is that it’s completely storage-agnostic, so it can theoretically be applied to any storage, given enough software development power.”
#3 - No Single Cloud Provider Should Be Able to Rebuild Original Files
Don’t put all your eggs in one basket, especially when it deals with personally identifiable information, or other sensitive information.
For this reason, It’s important to upload each piece to a different cloud object storage, so that no single cloud provider even has all the pieces necessary to rebuild your original files.
“If you put all of your files in a single container, in this case, a single cloud object storage provider, and that container is hackers, you’ve lost all of your data.
But if you slice your files into smaller chunks, then encrypt each chunk with a unique key, and then scatter those chunks around into multiple buckets-- when one of those places is hacked, all of your files are still safe, because unlike eggs, you need all the chunks that belong to a file and all of their encryption keys to rebuild and be able to open/access that file. So, thanks to our technology, even when one cloud object storage is hacked, the hacker still has nothing they can use in their hands.”
The Industry’s “Vendor Lock-In” Problem
It appears that our security industry doesn’t address these types of issues head on until after a breach occurs. So, why hasn’t this clearly documented issue been addressed more aggressively?
Simonetti believes this is due to a “vendor lock-in":
“...they don’t want their customers to spread their data and money across multiple cloud vendors. The goal of each cloud vendor is to maximize their profits, and make it as hard as possible for their customers to leave them behind and switch to a different cloud vendor.”
A goal, which according to Extenua’s security officer describes as a conflicting philosophy for best security practices which were explained above. “If you’re Amazon Web Services (AWS), why would you recommend to your customer to put part of their data in Microsoft Azure or Google Cloud, right? They’re trying to increase their profits, not their customers’ security.”
From an uploader’s perspective, they are still uploading a single file; nothing has changed. But taking into account the slicing, chunking, encrypting, and scattering across multiple cloud object storage providers, you are now part of a completely transparent ecosystem, all carried out by a safe and secure API process.
For a company like Extenua, it makes itself very clear that their software is not an END-USER service; rather, it’s an API, or application programming interface, designed specifically for programmers to incorporate this level of storage security into their own web and mobile applications.
“Instead, the end user uses a mobile/web application the same way they’ve always used it, their experience doesn’t change, but they can enjoy a much greater degree of security if the developer of that mobile/web application has chosen to use Extenua’s API to store their customers’ data safely in the cloud.”
Ultimately, in tasking programmers with securing corporate data, Extenua wants to encourage developers and programmers from any company to try these API packages. At the end of the day, API isn’t for everyone. The customer is almost invariably a corporation, with the actual user always (and required to be) a developer/programmer. The purpose of API’s in our digital world is to be used/integrated into some type of corporate workflow by a software developer/programmer.