Cloud Service Attacks: Consider a New Approach to Cloud Security
[This article was originally written by Nick Piagentini.]
Do you like perusing around on eBay while listening to your playlist on Spotify? Both services were recently compromised and are requesting users to change passwords and update mobile applications. It seems like these announcements are popping up more frequently than ever. It does remind me of a digital version of whack-a-mole, where the last defense against the pesky re-appearing varmints is to reset passwords and applications for consumers. But how can organizations reduce the unforeseen or unprotected paths to compromise, especially when cloud services are involved and are scaling daily to adjust to the consumer demand?
First, Heartbleed drove home the importance of not using passwords across multiple sites, and showed us how much we rely on a handful of common building blocks for most of our secure communications. Now the incident at eBay serves as another round of cyber mole exploration. As far as we know, the attackers did not exploit vulnerabilities on eBay’s servers; instead they used stolen employee credentials to access the eBay network and the sensitive data. We do not yet know the nature of the exploits used to gather the employee credentials that were leveraged to gain access. What has been released is that the attackers “compromised a small number of employee log-in credentials”. Most likely these employees were targeted through email or social media with tailored phishing attacks. The scope of the compromise as reported by eBay was a compromise in late February and early March, but yet wasn’t discovered until early May. The weakest link in the security chain once again is the user.
Spotify announced they had somebody somewhere with unauthorized access to their systems and ‘internal company data’. The reported scope of the compromise was one user account, but the compromise prompted Spotify to prepare an update for their Android app.
What steps can be taken to mitigate attacks similar to this? Three controls can be implemented to defend against the varmints trying to get through your organizations protections. In the shift from network-centric technology to user and server-centric verification and detection, these represent effective methods to protect the ever-increasing number of cloud-based resources that are harder to secure with traditional security tools.
1) Multi Factor Authentication. By making a privileged user password, a combination of something they know (their traditional password) and something they have (a token or cell phone), we significantly reduce the risk posed by an attacker learning only one part of it. Without access to the user phone or token the stolen password is of little value.
2) Continuous Monitoring of Privileged Access Control. This is a broad topic, but it boils down to the idea that someone needs to pay attention to who is asking for what information, when they are asking for access and review this in a timely manner. Just because a user is allowed access to data, should s/he be accessing it now, at this specific time?
3) Host based Intrusion Detection. With valid traffic being used to access the sensitive resources, the focus of intrusion detection needs to move from the network to the host. In this scenario, the unusual behavior is happening on the system itself. By monitoring what is happening on the servers, we have the chance of noticing the atypical behavior of the attackers.
Information Security has always been a race, and defenses have to adjust to the environment and risk at hand. Attackers are constantly improving their tactics and finding new vectors to exploit. Unauthorized activity should be detected quickly and a plan should be put into play to whack these moles efficiently. Applying visibility first and building to an automated approach to cloud security might be a better defense against these pervasive varmints that most likely will continue to infest our digital lives.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)