Mitigate Common Attack Paths at the Core

Last week I wrote that encryption probably wouldn’t have prevented the Anthem breach. The details of that attack haven’t been released, but I found some CSO Online’s analysis that pieces together how it may have happened. From there, I constructed the hypothetical Anthem attack path shown below.

CSO Online suggests the attacker could have done some intelligence gathering on Linked In, fingering Anthem employees with heavy database experience as the likely admins. And using that information, move on to Step 2, social engineering, with phishing messages to those admins. A successful phish could lead to Step 3, compromise credentials, potentially by planting keylogger-capable malware on an admin’s device.

Have you looked at your admin’s Linked In page lately?

To inhibit Steps 1, 2 or 3 use strict social media usage controls, better anti-phishing email and web filtering controls and much better endpoint security. It may be possible to effectively deny external hackers the ability to identify admins and make it more difficult to compromise their endpoints or credentials over the Internet.

But its not possible to secure the end user and device layer completely for thousands of employees and devices. A new, slightly longer attack path could still work, much as was reported with the RSA SecureID tokens breach breach a few years ago.

The figure below assumes that although cyberattackers could not identify or compromise admins directly, they were able to compromise devices of other, less privileged employees. What was Step 3 expands into Steps 3.1, 3.2 and 3.3a or 3.3b as the attacker moves laterally through the enterprise infrastructure to zero in on the targets.

Have you hardened your internal network to rid it of vulnerabilities and anomalies?

Once inside the typical organization’s network, its very hard to prevent attackers from moving on to step 3.2, gather inside intelligence by reading emails accessible to the compromised employees’ devices, accessing intranet web services and scanning the network. To mitigate internal intelligence gathering by attacks, encrypt emails and run most operations on a need to know and/or least privilege basis. Use tools to monitor and alert on suspicious patterns of directory access such as those we wrote about in Lateral Movement: There’s No Patch for Privilege Escalation. Do a better job of patching and configuring servers and services. But you can’t fix every vulnerability.

Slowly but inexorably the persistent attacker’s knowledge of your network scope of penetrated resources will grow, eventually to the point of step 3.3a (compromise admin) or step 3.3b (compromise app service). Soon you’re looking at an RSA SecureID breach scenario, where attackers are poised to query the database, or alternatively – as seen in the Target and Home Depot breaches – spread malware into your business ecosystem (such as point of sale devices).

Is your last line of defense your best, your core defense?

All too often, the answer is “no.” As I quoted Securosis in last week’s post, “Once they get the right admin credentials, it’s game over.” 

Assuming the breach moves onto step 4, query database, its harder than you think to stop it in the typical network. Smart attackers will take their time, and pull data out from the database slowly in ways that may appear indistinguishable from normal activity. They may transfer data off of the compromised devices or servers onto staging servers, and again exfiltrate it from the network slowly so that even a good data loss prevention (DLP) system won’t detect them.

A growing number of security pros are getting the notion that its time to protect your core, or harden the soft underbelly of IT. All too often, privileged administrator accounts enjoy virtually unrestricted access to highly sensitive or critical business systems, applications and services that are not tightly managed or monitored commensurate to the risk. Even if the data is encrypted at the storage level privileged admin accounts can get to it. 

Five Recommendations to Protect the Core

Bottom line: You have to assume attackers will – sooner or later – arrive at the core. User awareness training and policies on social media, better Internet filtering, better endpoint security and better vulnerability protection are necessary but not sufficient. At best they can cut down the noise so that you can concentrate defenses at the core.

Consider the following Security Architects Partners-recommended solution classes to mitigate common attack paths at the core:

• Privileged access management (PAM): Use PAM tools to protect shared accounts, superuser accounts, and all privileged user or application service accounts in or connecting to the core. Enable two factor, or cryptographic authentication to the PAM systems.
• Data masking: Most data access and system administration need not even touch all the plaintext sensitive information, such as much personal health or financial data. Mask or tokenize it. Protect the database containing just the plaintext as “the core of the core.”
• Database audit and protection (DAP): Not only can DAP tools provide the masking or encryption, they can also monitor for anomalies at the application layer.
• System change monitoring: After an extra dose of configuration hardening and vulnerability management for core systems, install tools to monitor for changes, and investigate unexpected changes.
• Network zoning: Segment and restrict access to core internal networks. Monitor the rates and types of internal traffic for anomalies. Minimize trusted connections that let data flow in the clear. 

Note that our five recommended core defenses neatly traverse the architectural stack – identity, data, application, system and network. Notice that they’re all complementary – for example, a zoned network has fewer unexplained or seemingly random traffic patterns, which simplifies anomaly and change monitoring at all layers. 

Understand some over-arching, implicit considerations. First, you have to map the core to understand not only where your digital jewels are kept, but all the use cases in which they’re exposed to users, applications, operators, managers and vendors. Inventory and dependency mapping, in other words. Second, you have to verify the core defenses are working through frequent system or log inspection and occasional penetration tests. Third, all this presumes a reasonable governance structure is in place.