Some Reasons Behind Cloud Security Vulnerabilities
We have debated back and forth that the Cloud is just as safe as the traditional enterprise option, and even more so. Combined with all the advantages, it is a better option for today’s business world. But the security fears are always just around the corner and pops up again every time there is a discussion about Cloud migration. These fears are not unfounded however; they are very real but quite containable unless they were not considered during migration to the Cloud.
Organizations looking into Cloud security like HP have found very simple and obvious yet often overlooked reasons for the security vulnerabilities that happen when applications and data are migrated to the Cloud. Most of the vulnerabilities are caused by overlooked and unchanged settings when applications and data have been migrated. Here are a few of them.
1) Unchanged hardcoded communication channels
Most enterprises have data policies that have been enforced in their data centers and have been considered as fairly secure. Settings like encrypted or unencrypted data channels, harcoded IP addresses and hardcoded hostnames. These are all fine internally because the data center environment has been evaluated for security and these settings were made for exactly that. But when the data is moved to the Cloud, all the channels become public so internally secure processes like passing plain text content over the network suddenly becomes a huge vulnerability. That is why all migrated programs and applications should conduct all the previously safe intra-component communication over secured and encrypted channels. All of these settings have to be changed to accommodate the change in the control of the network infrastructure.
2) Unsecured logging system
Logs are very important for the enterprise. It allows administrators to diagnose problems and as a forensic tool to find evidence in the event of an attack. Enterprises often have strict rules which govern their logging system and dictates what exactly can be logged and who are privy to this sort of information. These rules are strictly policed and enforced regularly. But when the system is migrated, these rules do not apply anymore. And to avoid repercussions and accusations later on, these rules must be reviewed and reapplied to the Cloud environment through the SLA with the Cloud vendor. This ensures that data logging cannot accidentally leak towards malicious individuals. Attackers can use the log data to determine the vulnerabilities of the system; it is very rich and for hackers. The logging should be minimized, reconfigured and controlled, or even turned off.
3) Adjusting encryption for virtualization
Mirroring of an entire system is a very common practice when provisioning virtual environments. This means that a specific vulnerability with the parent system will ensure that all virtual mirrors will have that same vulnerability, giving an attacker hundreds of doors which can be opened by a single key. Virtual instances must have different encryption keys, so they should never be hardcoded. Hardcoding in an internal data center environment might be fine, but that should be changed when the system goes Cloud.
All of these vulnerabilities are because of the difference in the environment that the system will be residing in. Most of the time migration is so painless because systems work immediately without much tweaking that these very important security liabilities which were not issues before have been ignored and carried over in the public environment. The only solution is a reevaluation of the system’s security after migration and changing all of these variables.
By Abdul Salam
He has recently co-authored: Deploying and Managing a Cloud Infrastructure: Real-World Skills for the CompTIA Cloud+ Certification (Wiley).