Cloud Security Breaches and How to Avoid Them
The cloud is expanding. More applications are being run online. More data is being stored online. More businesses are relying on public, private, and hybrid clouds for their apps, records, and backups. And more hackers are taking advantage.
Why Security Breaches Happen in the Cloud
Hackers aren’t attacking the cloud; the cloud is their access point to attack your business. CIO.com found that 85% of IT professionals are confident in the cloud provider’s ability to provide a secure environment. CompTIA’s Annual Information Security Trends found that only 29% of IT users heavily review their cloud provider’s security policies, procedures, and capabilities.
The numbers speak volumes: 85% of us are confident in the cloud provider’s ability to secure our data; yet only 29% of us heavily review that same ability. Cloud providers like Amazon Web Services and VMware are wonderful organizations who make security a top priority. However, blind trust in anyone but yourself is bad business practice. Let me explain . . .
Cloud Security Risks
The CSA’s “Notorious Nine” cloud computing threats define the risks of cloud computing. Though the list includes important considerations like data loss, account or service traffic hijacking, denial of service, and others, first on the list is data breaches.
Why Does the Cloud Attract Hackers?
Because they can easily infiltrate multiple targets. A research paper published by university computer scientists and researchers from RSA Laboratories devised a virtual machine that can extract private cryptographic keys stored on a separate virtual machine when it resides on the same piece of hardware. It can be even easier than that – if a multitenant cloud service database isn’t designed properly, a single flaw in one client’s application could allow an attacker to get at not just that client’s data, but every other clients’ data as well.
Is There a Way to Ensure Data Security in the Cloud?
There is. It takes 3 steps.
Verify Cloud Provider’s Security Protocols
Only use providers who are proactive (not reactive) about their cloud security. Amazon, VMware, and IBM are great examples. They should constantly be examining weaknesses and vulnerabilities in the platform.
Get proof that your cloud provider’s architecture and systems have been audited, giving you peace of mind that the systems meet regulatory compliance even if you are not required to meet these regulations yourself. Ask if the cloud provider is FISMA-certified (indicating a high level of commitment to data security), and whether they are certified for compliance with PCI DSS, ISO 27001, HIPAA, and FIPS 140-2.
Do Not Trust Anyone But Yourself
Always remember, regardless of the security protocols of your cloud provider, the business that owns the data is responsible for its cloud security. If possible, they should have a CCSP in charge of this. Make sure you can encrypt your own data and use the industry’s strictest standards to do so. Always use split key encryption to ensure that only you have access to your data. By using this technology, even if an attacker gets in, your data will be unreadable and they can move on to someone else.
Take your security to the next level by homomorphically encrypting your encryption keys. This way, even while keys are in use in the cloud, they cannot be hacked.
Run vulnerability scans and/or full penetration tests regularly. You may even want to hire a firm to do so. This way, you can be sure that hackers cannot access your records and rest easy knowing that even if they do gain access, your encryption will render your data useless to them.
Cloud Security Breaches: Avoidance and Protection
Breaches happen every day and they are detrimental to business (just ask the CIO of Target). But that is no reason to stay earthbound and delay your migration to the cloud. First, breaches happen in datacenters too. Second, the cloud’s benefits are tremendous, and there are great providers out there and ways to avoid breaches and protect yourself in the event that a breach does occur.