The Need for Security-Specific Applications

When we talk about cloud providers, we often forget that not all data is the same — even in the same application, while we might think of this data as from a “financial application” or a “computation process”, the reality is that each data set has subsets upon subsets, and thus require specific applications to manage them.

This is part of the problem of data security. While it’s tempting to just put all of that data your organization collects into a store, password protect it, and call it a day, many data types need additional security protocols, additional gates for encryption and hashing, and in some cases, an entirely different method of managing data in general.

Failing to recognize this is not just a miscategorization, either — in some cases, it can be extremely damaging to your data security, giving you a false sense of meeting security standards while failing to protect your consumers and customers. In other cases, it can even result in a worse security posture, providing you with a false sense of security when that security is legally, ethically, and technologically insufficient.

Identifying Data

How, then, do we identify this type of data? Simply put, you can broadly categorize data by their specific purposes, the source of that data, and the governance applicable to it. While this is not an exact science — in fact, this should already have been done before the data was ever collected — broadly sorting this data into specific categories is the first step.

There are a range of governance requirements that you should first identify. On the international scene, this data protection is much more extensive, but regardless of whether the protection occurs in US jurisdiction or international markets, the separation is largely between financial, governmental, sensitive, and general.

Financial data is any data that is governed by laws such as the PCI-DSS credit card data protection standard and other specific data laws. Governmental data, of course, is typically handled using specific governmental edicts, and is negotiated as part of the Service Level Agreement made between the contractor and the governmental office.

Sensitive data, specifically data such as healthcare information, is typically protected by industry specific protections like HIPAA. FInally, general data is not necessarily protected by any law in many jurisdictions, with the exception of personally identifiable information that is bundled with other general information, such as is found in cloud provider databases and registration stores.

Securing Data in the Cloud

With all of this in mind, how do we specifically secure this type of data? The first step to take is simple — isolation. The main problem here is that not all data is the same — some data will require high security solutions, and other data is appropriate for over-the-clear transmission. While higher security systems exist for their given criteria, this security comes with a cost — thus, applying this same highly secure standard to all data means that cost is spread across data types that won’t benefit from it, and thus don’t justify the cost.

Once you have your data isolated and divided into their appropriate types and domains, the next step is to look at the underlying architecture that it will integrate with. Code wants data to be free — the utilization of data is the function of any program or application and thereby the underlying architecture. In order to secure this data, you need to work against its natural inclination. This includes securing endpoints that face the public, implementing rate limiting systems to prevent mass attacks or data export, ensuring data is encrypted and hashed both at rest and in transit, and implementing proper access controls.

Of note during this phase of consideration is the fact that, in some jurisdictions with certain types of data, it’s almost as important to consider who runs the architecture as it is to secure the architecture itself. For many governmental data sources, the content must be processed on US soil by cleared individuals and in a specific physical design — in these cases, you could have the most secure servers in the world, and improper fundamental control considerations would negate them all.

Fundamentally, the argument here is less for being concerned about architecture from a general point of view, and more about being concerned with specific regulatory points of view. By matching the solutions to their regulatory-compliant implementations, one can secure data in the cloud with a high degree of accountability, auditability, availability, and confidentiality.

A Case Study — GovCloud

One example of a security-specific cloud application would be GovCloud, an AWS offering. GovCloud is specifically designed with all the considerations laid out above, setting itself up to offer secure cloud computing for workloads that are anything from unclassified to regulated.

It does this chiefly by implementing a few limitations as to what technology is used, and who utilizes that technology — in fact, GovCloud boasts that it matches a large amount of standards requirements, including FedRAMP, FISMA, and DoD SRG protection levels, US International Traffic in Arms Regulations, the IRS Standards for Federal Tax Information, and many more. By matching the technology to the standard of the associated regulations, these solutions automatically offer a compliant framework from which to host such data. From here, everything becomes an operational concern — i.e., security becomes a concern centered around preventing phishing, providing proper access control, and more, rather than securing the actual physical systems hosting said data.

Security as a Weak Link — Configuration

The caveat with this sort of solution, of course, is that it’s only as good as the configuration governing it. No matter what implementation is chosen, its configuration can either strengthen or nullify securing efforts. Accordingly, once a secure solution is chosen and the underlying concerns are addressed, configuration should be checked and assured.

One easy solution to this configuration quandary is an automatic scanning system like Cloudsploit. An automatic scanner looks at the various settings hidden throughout the AWS configuration systems to ensure that the infrastructure is not compromised due to an errant setting. Remember, this secure system is only as secure as its weakest point — and that weakest point arising from misconfiguration is likely the easiest and most impactful to fix.

These types of weaknesses can be in any of a wide variety of categories. Simple issues like not securing the database itself from public viewing has resulted in a wide range of exposures in recent years, and is still a major threat. Open security groups, which allow privilege escalation, poor root account security, and even simple issues like providing too many rights to basic users can take what is otherwise a secure installation and make it no better than a public system. In many instances, it can actually make it worse — the only thing worse than having poor security and knowing about it is having poor security but believing that you have a secure system instead.

Conclusion

There are a wide variety of secure offerings in the cloud space. These offerings are often security-specific, and in many cases are application-specific. With the proper considerations of underlying integrations and systems which work interoperably with your secure implementation, these offerings can provide a high level of control and security that is unparalleled in cloud computing. That being said, misconfiguration concerns still rear their ugly head with these offerings, and as such, automated scanning should be employed to ensure proper security is established and maintained.