InfoSec Musings: June 2014

Yes, I agree that I'm late to the table on yet another Target Breach Blog, but I want to throw a twist on the story..

A fantastic "WHAT IF?"

I want to transport you momentarily, to a utopian world where Large Corporations understand that firewalls and segmentation do not provide complete security anymore (probably never did), and that to truly protect your Infrastructure, Applications, and Customer Data, you need to do so at the host!

The very servers upon which your intellectual property resides need to be your front line of defense.

First, lets spend a minute reviewing what we know...

Brian Krebs, of Krebs On Security has meticulously documented and unraveled the timeline and events that led up to the actual Breach. I will not reiterate all the gory details here, but will refer to his findings along this journey...

Of specific note: As of this date (June 13rd, 2014) We still do not *know* for certain how the attackers got into Target's internal network, nor how they escalated privileges to install their malware.

Krebs, Dell SecureWorks, and Malcovery have collected strong evidence to support a hypothesis. We do not need to fully understand the mechanics of the breach to conjecture a remediation strategy for those who have not identified their breaches as of yet.

In a nutshell, the attackers launched a phishing attack some time in October 2013, and managed to compromise one of Targets vendors. The credentials for this vendor most likely gave the attackers access to Target's Online Billing system. Coupled with a large amount of publicly available documentation intended to assist vendors in accessing the system, the attackers were able to capture enough detail of the Target network and Active Directory Infrastructure to launch a SQL injection attack. It is believed that they used this SQL injection attack to install tools used in the remainder of their exercise.

From the Dell SecureWorks documentation:

They were able to install three different sets of malware to enact their scheme: First, they added a variant of a previously known Point Of Sale memory Scraper. This application would monitor the active processes memory on the Embedded Windows POS endpoints, and capture anything resembling Credit Card information. The application would then periodically ftp that information to another server that was compromised through a privilege escalation in Active Directory. Yet another compromised system would pick the data from that ftp service, and deliver it to several external ftp sites.

All of this happened right under the noses of the very people employed to protect the network and it's data.

(trust me... you want to read that link!)

The immediate questions being:

How did they compromise a public facing application to get "inside" the Corporate Network?
Why were 3rd party credentials on an external facing application associated within an Internal Directory?
Where was Intrusion Prevention between their DMZ and the Corporate Network?
How did an Admin Account on a single server get privilege escalated to the Active Directory?
Once in the Production Environment, how did they get to the POS network? I mean they are PCI compliant, aren't they? There should be no direct path between the two...
Where was Intrusion Prevention between the corporate network and the POS network?
How was an FTP service allowed to communicate from the Data Center out to the Internet?
Where was Intrusion Prevention between the Corporate Network and the Internet?
If IPS was in fact in place (I have to believe it was...) was it detuned or ignored?

Target isn't talking, so....

Lets assume for the sake of the remainder of this posting, that they had put a Zero Trust security model in place. How would this scenario have played out? What are the points of contact that would have raised alerts/sounded alarms?

In a true Zero Trust model, there would not only be network segmentation between zones of trust (production, dev, test), but between the tiers of an application stack (presentation, application, data). Applications, and Lines of Business would be segregated from one another as well.

Where there were zones containing or processing sensitive data, the demarcation between such segments would be augmented with addition controls such as Intrusion Prevention, Data Loss Prevention, Network AntiMalware. Privilege Password Vaults would be used to manage any level of administrative access required across the board - Windows/UNIX/Mainframe/Network...

Seems like an impossible task? Too late to retrofit into an existing production infrastructure! It will never work!!! Or... Can it?

The cost, both financially and in time, would be extremely prohibitive to retrofit an existing corporate network. VLAN segmentation, layer 2 and layer 3 firewalls, as well as a myriad of network security appliances are needed to inspect and enforce traffic moving between hosts...

But what if you could make the the servers themselves complicit in the overall security?

Symantec: Protecting PoS Environments Against Multi-Stage Attacks

By having a properly configured and managed host based security suite in place, applications residing on those hosts would only allow traffic communications from known sources, on known ports, using known protocols. Attempts to brute force passwords, scan ports, or escalate privileges would not only be immediately blocked at the server being attacked, but all other systems within the management policy. Alerts would be sent to the Corporate SIEM, and multiple layers of alarms would be generated. If a server were actually compromised, the incident could be contained to that one host.

You could gradually integrate the Zero Trust model into your environment, one host at a time, by creating Virtual Zones of Trust. Start with low hanging fruit, by grouping systems belonging to a common application, and applying a policy that rejects traffic from other applications, essentially "sandboxing" the application.

From my previous article:

A Host Protection Service must:

•Operate on the significant majority of our Host Operating Systems, and support all of our existing Database and Middleware

•Protect against Zero-Day malware and malicious actor attacks.

•Prevent unauthorized changes or actions, even if the perpetrator has administrative rights.

•Enable demonstrable change control on mission-critical systems.

•Centralize configuration protection across the enterprise, reducing administrative burden.

•Support a library of pre-defined rules that recognize common security events.

•Support policies across logical groups of hosts, helping to ensure the appropriate level of security and ease administrative burden.

•Run pre-defined and customized reports on policies and security events enterprise-wide across heterogeneous systems.

•Automatically trigger alerts and actions, based on pre-defined thresholds, when an event matches a rule.

•Record the event in a centralized corporate SEIM.

How could Host Based Protection have helped Target?

With Host Protection installed on the Point of Sale Embedded Windows OS terminals, a policy would restrict the system from accepting patches/updates, or installing software/executables from anywhere other than the official SECURED software distribution infrastructure. This would have eliminated the potential of an attacker installing anything, unless they had already compromised your software distribution infrastructure. The POS application would run in a "sandbox", basically a separate secured process that does not expose it's memory or connectivity to other processes on the host. This would have eliminated the potential for memory scrapers. Essentially, phase1 of the attack would not have been achieved.

With Host protection running in the core data center servers (both physical and virtual), there would be no way to install the data transfer software... even if you had the credentials to an administrative service account on the server. The Host Protection would only allow software updates, patches, or executables to be pushed from
the official SECURED software distribution infrastructure. If the data transfer software were already installed, then any change to the configuration of this software, even with a compromised administrative service account, would raise an alert, and log all activity to the console. If the alert was not responded to within a period of time, the configuration could be rolled back automatically. Essentially, phase2 of the attack would not have been achieved.

With no Phase1, and no Phase2... Exfiltration of the customer data through this methodology would not have happened, and CEO Gregg Steinhafel and CIO Beth Jacob would still have their jobs...

Additional controls to consider, beyond those provided by Host Based Server Protection:

Segment POS network from the corporately accessed network
Segment Database network from the corporately accessed network
Encrypt all transactions between POS network and servers outside POS network
Employ a Privilege Access Management Strategy
Enforce scheduled maintenance windows for software updates/installations
Enforce specific hosts/accounts allowed to deploy software updates/installations
Patch Applications as well as Operating System as patches become available
Use Heuristic Analysis as well as Signature based AntiMalware.
Subscribe to and USE live Threat Analysis Feeds
Do not log locally, but rather stream log events to a SIEM
Remove - not just disable - all not pertinent applications/executables
Run AntiMalware at your Internet Egress point, as well as on your hosts
Run Data Loss Protection on your hosts as well as at ALL egress points