Speaking Engagement: CMU INI

I will be a guest speaker for CMU INI graduate students next Friday, 2/27/2009. The abstract of my presentation is below.
Careers in Information Security and Tales from the Front Lines of Network Defense

In this two-part presentation, Michael will introduce the field of information security from a career development perspective, giving attendees a broad view of the industry and how their various academic backgrounds may align. As the lecture progresses, Michael will give an insider's view into what it's like to defend a network used for the design of the next generation of national defense technologies.


Rethinking the network perimeter

Does anyone remember bastion hosts? Marcus Ranum describes them in his 1993 paper on firewalls, just to give you an idea of how old the concept is. There was an obvious problem in the notion of a bastion host (as originally devised): having a "critical strong point in the network's security" provides a single point of failure and big target for exploitation. Leaving a system exposed, regardless of how secure it is believed to be initially, will inevitably lead to failure. The principle of least privilege needs to be enforced at the network level. Thus, we created the notion of the DMZ.
Naturally, the notion of a bastion host evolved to be a not-so-exposed system, partially protected by firewalls and isolated from the internal network so as to mitigate the damage resulting from compromise. The crown jewels are, by this model, inside the LAN and isolation was tantamount. And thus have we operated since...

Naturally, this model has made various evolutions. Initially, the focus on protection was outside-in. Various pressures - security, policy, and otherwise - necessitated greater control on network egress. If you want to make sure a compromised internal system can't arbitrarily funnel data outbound over some ephemeral port, you need to restrict what services can be accessed on the internet from clients on the LAN. If you want to keep your employees from surfing pr0n on the job, you needed to be able to restrict what web sites they access. From this came proxied services: HTTP, DNS, email, and other services now must be funneled through a relay for greater control.

Do you see what's happening here? Our control over our networks has slowly crept up the OSI model as we realize the perils of a lack of control over the next layer up. From the flat networks of the early 80's, to segmentation later in the 80's and early 90's, to control over the transport layer with firewalls, and finally up as far as the application layer with insistence on proxying all services in the most "secure" networks accessing the internet today, our defenses were pushed upward by adversaries who understood how to exploit the lack of control at higher layers.

I've got bad news: even this isn't good enough. While we've definitely raised the bar for adversaries, they have nevertheless stepped up to the plate. How do you compromise systems and funnel data out of a protected network which insists upon protocol compliance and restricted connections? Obey the rules. Comply to the protocol. Repurpose the available communication points outside of the network. And this is precisely what adversaries are doing.

If you didn't already know, I'm telling you now: protocol-compliant command-and-control channels that communicate to compromised websites are all the rage in sophisticated attacks today. How can one attack a computer? Use the inbound communication channel: email. How can one establish bi-directional control over a compromised host? Use the outbound data channels to initiate a connection, and proceed from there: HTTP, DNS, email, these all permit bi-directional communication to every workstation in a protected network connecting to the internet today.

What does this mean? It means that every host which can participate in these types of data transmission is an internet-facing host. Bastion hosts, firewalls, proxied services, all exist in vain against these techniques. This is the very point of this whole post: your most exposed hosts are your workstations. And today, in 2009, you have as many internet-exposed hosts as you have workstations. Considering that today, all work is done on workstations, this means your data is residing on the most vulnerable systems on your network - even if only temporarily while in active use or development. There are many implications here, which I won't go into, beyond to say if you've been sleeping soundly because you believe your network controls are strong, I hope you've enjoyed it.

Update: Somehow this got back-dated... fixing.


Irresponsible disclosure

Did you know that last year, Heartland Payment Systems suffered a data breach that "may have compromised tens of millions of credit card transactions?" Me neither, until I received a notice in the mail that my card may have been one of the ones compromised. Why hadn't we heard of this? Perhaps because Heartland decided to announce the data breach... wait for it... on inauguration day. Curious timing, don't you think, considering the breach happened last year?

A few other confounding aspects of this breach:
  • The date of compromise is unknown
  • Heartland had to be notified of this by Visa and Mastercard. They did not discover it on their own.
  • Transactions occur unencrypted, according to the bankinfosecurity.com report: 'Data, including card transactions sent over Heartland's internal processing platform, is sent unencrypted, he explains, "As the transaction is being processed, it has to be in unencrypted form to get the authorization request out."'
Heartland boasts their advocacy for end-to-end encryption despite that last bullet:
For the past year, Robert O. Carr, Heartland's chairman and chief executive officer, has been advocating for payments industry adoption of this technology — which will protect data at rest as well as data in motion — as an improvement for payment transaction security.
Certainly this claim seems dubious. In any case, the data capture and exfiltration appears to be enabled by malware installed on hosts in their payment systems network. Disk, database, and transactional encryption won't prevent compromised hosts from having access to the data in clear-text form as it's processed - clearly, this data must be unencrypted at some point in the process in memory (at least).

This is a whole bucket of fail right here.