Limits of Amazon Web Services Security Controls and the Need for Deception Technology
Guest Blog By:
DS Applied Engineering
Enterprise architect, research scientist, and author
Amazon Web Services (AWS) offers a range of robust security controls but relying solely on AWS to ensure information security is a mistake. Amazon makes clear that public clouds entail a shared security model. Amazon will manage physical security, implement network security, lock down hypervisors, and provide tools, such as identity management services and virtual private clouds, for customers to use as needed. Customers, in turn, are responsible for implementing access control policies, monitoring systems, and assessing applications for vulnerabilities.
Let’s assume that infosec-savvy customers follow AWS security best practices. Virtual private clouds and network access control list control the flow of network traffic into and out of a company’s cloud infrastructure. Access control policies and identity management controls limit users to the minimal set of data and applications they need to do their jobs. Code reviews and vulnerability scans subject applications to rigorous examination before they move into production. System administrators use AWS Cloud Trail to monitor events across platforms. With all these controls in place, the infosec-savvy user has clearly used all reasonable tools at their disposal, right? Wrong.
Even following typical best practices for securing networks and servers while granting users least privileges and mitigating risks of application vulnerabilities, there are two substantial and unaddressed risks: phishing attacks and advanced persistent threats.
Phishing attacks exploit communication channels such as email to lure potential victims into downloading malicious software or otherwise perform some compromising action. Phishing evolved since attackers figured out that attacking an employee’s device is easier to attack than a server and as a response to anti-malware that could detect and block malicious code before it reached its target. Instead of directly delivering malicious code in an email, phishing lures are designed to trick the recipient into performing an action that the attacker cannot perform independently. Phishers take advantage of the fact that communication channels, like email, are sufficiently open that they can begin an attack through these channels and once inside can look for other vulnerabilities to exploit.
This leads to the second risk: advanced persistent threats (APTs). Patient attackers can spend significant amounts of time probing for weaknesses and building on small successes. For example, an attacker may trick a user into downloading a remote control application through a phishing lure. The remote control program might then scan the network and build a map of the corporate network structure. It could also scan scripts looking for login credentials to databases or other applications. Once it has those, it can continue to build to the attackers ultimate goal such as stealing confidential data.
In both the case of phishing and APT, there is no single block-and-tackle type of security control we can deploy to disrupt these attacks. Instead, it is better to lure attackers using deception technology into attacking a realistic looking device that actually harbors monitoring tools to collect data on the attackers tactics and tools. This offers two benefits. First, it slows the attacker from reaching actual production devices while they expend effort on the decoy. Second, it allows infosec teams to monitor the attackers tactics and collect data about their methods.
Also, keep in mind that most of the existing prevention solutions (IPS, Sandboxing etc) are deployed to inspect North-South traffic and do not scale well to detect lateral movement in East-West traffic. Once the attacker breaches past these solutions the lateral movement happens across East-West traffic. Deception technology scales well and can be deployed across the data center to minimize the threats.