CSPM Archives

We’ve all heard about the CapitalOne breach. It dominated headlines for weeks and is a prime example of how even the largest and best trained organizations – ones who clearly put security at the top of their mind – can fall victim to sophisticated cloud attacks. But buried in the news about this massive breach was a very interesting, and far less talked-about detail: the hacker who breached CapitalOne also attacked at least 30 other organizations. Think about it for a moment: One hacker. Thirty organizations. How can a single hacker achieve such scale? It’s simple: with automation. Attackers Use Automation for Scanning & Exploitation Automated tools have become a common component of hackers’ toolkit. While many of those tools are labeled as ‘ethical hacking’ or ‘testing’ tools, they are also frequently used by hackers while they are performing reconnaissance against potential targets. Here are a few common tools used for reconnaissance and penetration of applications and cloud networks: Shodan Shodan is frequently called the ‘search engine of hackers.’ It is a search engine which indexes data from any type of internet device connected to the internet, such as computers, servers, mobile phones, webcams, online storage buckets, etc. In the world of cloud computing, tools such as Shodan (and others like it) are particularly useful in identifying publicly exposed VPCs and storage buckets, and testing them to see whether they are secured or not. Nmap Nmap (Network Mapper) is an open-source tools used for network auditing and mapping. Some of its capabilities including identifying hosts and inventory within a network, detecting open ports, querying host data such as OS and services they are offering, as well as testing them against various exploits. OpenVAS OpenVAS is an open-source tool used to detect remote vulnerabilities on applications and networks. It includes robust web UI with tens of thousands of different vulnerability tests, as well as supporting multiple host scanning, run scheduled scans, as well as evade detection systems. Wapiti Wapiti is another open-source command-line utility, which can detect a whole range of web application vulnerabilities including SQL injections, cross-site scripting (XSS) attacks, XML external entity (XXE) injections, server side request forgery (SSRF) attacks (the same attack used in the CapitalOne attack), and others. Although not as well-known as some of the other tools, it is nonetheless a very robust tool for detecting web application vulnerabilities. This list is just a sample of dozens of other tools out there. While many of those tools are intended for use by infosec experts and security professionals, they are also frequently used by hackers, who leverage them to identify weaknesses in target networks – and exploit them. Close the common vulnerabilities So what can you do, you ask, against such an array of automated scanning, reconnaissance and exploitation tools? Well, you should use your own automation. Using defensive automation procedures, you can prevent easily-exploitable vulnerabilities, and automate detect of attacks if-and-when you are penetrated. Some common vulnerabilities that can be closed with defensive automation: Publicly exposed assets: running in the public cloud makes it very easy to spin up new resources, and just as easy to forget to secure them. Automated defensive tools can help you identify publicly exposed assets and make sure they are secured. Cloud misconfigurations: make sure your cloud environment does fall prey to some common cloud misconfigurations, which cane make your cloud network vulnerable to penetration and exploitation. Excessive permissions: Public cloud environments are notorious for granting unnecessary permissions to users who have no business need for them. Intelligent permission analysis methods and smart hardening procedures can help you crack down on excessive permissions, thereby limiting your threat surface, without interfering with business activities. Compliance violations: since cloud security is frequently a black box to many organizations, one of the first objectives for many organizations migrating to the cloud is to make sure they are in compliance with national and industry standards which apply to them. Defensive automation can help you identify any compliance requirements you might not be meeting, and how to fix it. Assume You’re Already Compromised The number of threat vectors and attack surfaces to protect against is almost infinite, but getting started on the vectors listed above is a good start, and will go a long way to making sure your data is protected. However, since the threat surface is so large, it is virtually impossible to guarantee that hackers won’t make it in. This is why it’s you should work based on the assumption that penetration is a matter of when, not if. Put differently, you should assume you’ve already been breached (or will be eventually), and plan accordingly. Using automation, there are a number of different activities and procedure you can start doing now, for when that fateful day comes: Detection of Malicious Behavior: detecting suspicious activity in your cloud environment which is potentially indicative of data breach activity. Using a risk-prioritized detection engine will allow you to focus first on the alerts which matter the most. Correlation of attack events: there are many detection tools out there, and many of them can detect practically every peep on your network. And that is a problem, because what happens is that you drown in alerts. What you need, therefore, is an engine which doesn’t just detect events, but also correlates them into unified storylines which show you the step-by-step progression of attacks. Automated response: detection is only one half of the equation, and while many attacks take a long time to unfold, you want to respond as quickly as possible. This is why automated response is critical, to be able to stop attacks the moment they are detected, before any damage is done.

Results for: CSPM