I recently had the pleasure of performing one of the best security assessments I’ve ever done. It was great: I didn’t find any gaps. Not a one.

To some people, it might come as a surprise that I’d consider that a good assessment. And I’ll admit, it made me a bit suspicious. Nothing? Seriously? Well, I had to look into why, and I’ll get to that in a moment. But let’s cover something else first.

I’ve been on both sides of the table for security audits. Being audited is Not Fun. You have someone coming in, looking over all your processes, and it’s up to you to prove that you’re doing what you’re actually doing, often for reasons that seem terribly arcane or pointless. And the management directive is almost always “make sure we pass this” which is assuredly not the same thing as “make sure we are actually secure.” It’s a very adversarial relationship.

As the auditor, you’re always looking for the places where they’re trying to hoodwink you, trying to gloss over something, or just outright lying. You’re always suspicious. If you’re not when you start, you will be. Because the people you’re auditing don’t want to be secure – they want to pass the audit. Which is understandable – failure can mean losing their license to operate, losing a major contract (clearly, one that’s big enough to bring in an auditor!) and in extreme cases bringing down the company.

It doesn’t have to be that way. As a security analyst, my goal isn’t to find problems. It’s to locate any security gaps that may exist, and where appropriate offer remediation steps.

Aren’t those the same thing, though?

Well, no. As the old saying goes, “seek and ye shall find.” I’ve met many auditors who took delight in writing overwhelmingly negative, scathing reports. They’d pounce on any excuse to fail a control. Which sounds like they’d at least be informative, but realistically the resultant reports aren’t all that useful – they don’t give much true concept of the security posture of an organization, because they’re invariably negative.

The problem is that nobody is really looking at the true purpose of security audits and assessments. Organizations being audited just want to get through the audit. The auditors are trying to “catch” the organization. But security audits aren’t high school tests or witch hunts. The end goal isn’t the report. The end goal is an organization, system, or project with a good security posture and no known gaps.

That’s what made the assessment I did last week so unusual. You see, they were given the standards in advance. They knew exactly what I was looking for – and so they went out of their way to make sure I’d find it. They had purpose-built the space specifically to meet the standards. There was no gotcha, no hidden agenda, no posturing or hiding. I knew they’d set things up to make sure my assessment would be good – and that’s great. It’s the way it should be, and the result was a completely clean assessment.

Of course, there is a risk. Organizations may know what the standards are and then try to pretend to follow the standard, or look for loopholes. That’s where the auditor really comes into play – to recognize when an organization is trying to follow the letter but not the spirit of the standard. But the most important thing to remember, for both the auditor and the auditee, is that the goal ultimately, is security – it’s not to play gotcha, it’s not to hide gaps. It’s to find and close the gaps that exist.

So, SOPA is the news of the day, in terms of the Internet and security; it has been for well over a month now.
In case you’re not familiar, SOPA is the Stop Online Piracy Act. It will “authorize the U.S. Department of Justice to seek court orders against websites outside U.S. jurisdiction accused of infringing on copyrights, or of enabling or facilitating copyright infringement.”

I won’t bore you with the typical arguments about how it’ll infringe on free speech, or weakens safe harbor, etc. These arguments have been made, and they may have some validity, but let’s talk technology.

SOPA is the most recent in a long line of legislation intended to regulate the internet. Such legislation is doomed to failure. The internet was designed to be impossible to regulate. SOPA focuses on preventing search engines from directing users to sites, and ordering domain name registrars to delist sites. While there are other provisions, these are the primary tools for stopping piracy outside of US jurisdiction. They’re supremely ineffective tools, because neither search engines nor DNSes are necessary for the function of the Internet.

To understand this, let’s step back and look at what the Internet really is.

The Internet, or rather its precursors, were created in the 1960s as a result of an initiative by DARPA – the Defense Advanced Research Projects Agency. DARPA is notable for investing in all sorts of interesting projects that might have military applications – many are successful, and result in some of the most powerful technologies of our time. Granted, many are pretty off-the-wall and don’t look like they’ll ever amount to anything, but that’s the risk you take.
The Internet was created to enable communications even against attempts to disrupt the network – even against the loss of most metropolitan areas, such as might happen during a nuclear war. This is actually very hard to do: you have to come up with a design that works even if all of your central nodes are gone.
The Internet as we know it today has a number of elegant solutions which make it the most robust communications network ever known.
The first is in the data packet. All data sent on the Internet is broken up into packets – even when it’s called “streaming”, it actually consists of content that has been broken up into separate packets which are then reassembled at the destination. Each packet, in turn, has a portion that says to where the information is going (the address) and a portion which contains the actual data (payload). This means that any given packet can be lost or corrupted, and the entire rest of the message will still get through. Granted, with encryption or compression this might be a moot point, but on the other hand with error correction it can actually be made even more robust.
Beyond that, there are the routing protocols. Various routing protocols work somewhat differently in ways that are hard to describe, but they all serve roughly the same function. When a router receives a packet, it looks at the destination address and tries to find a route to that address. What’s especially clever is that if a given route fails, the router can then select an alternate route. In this way, the Internet can be self-healing. Bandwidth might drop as alternate routes are used, but so long as a path exists the message can still get through. And that path isn’t limited to even the same medium as was used in the past: Internet data can be sent over copper, satellite, radio, laser, physical media, even carrier pigeon!

Now, I haven’t mentioned DNS or search engines so far. That’s because we don’t need either.

DNS – Domain Name Service – is a technology that renders IP addresses into human-readable names. The addresses to which I alluded earlier are numerical. In IPv4 they’re a 32-bit binary number; in the newer IPv6 they’re a whopping 128 bits. Rendered into decimal, they’re a bit more manageable, but not by all that much – would you like to memorize strings of numbers like “192.168.15.106” for every website you visit? DNS is a service that your computer accesses which translates the much easier to recall names, like www.google.com into 74.125.227.147. It’s a nice convenience, but you don’t actually need it. And you’re not locked in to any one DNS server – you can set up your own, or you can actually use one that’s based outside of US jurisdiction.

And search engines?
Same thing – they’re a convenience. There isn’t even a specification on what a search engine is. And as you doubtless know, you can use whatever search engine you like, again including ones that are based outside of US jurisdiction.

There are technical solutions to these oversights, of course. But, thanks to the structure of the Internet, there are workarounds for those as well. The Internet was designed to be hard to disrupt. From a technical standpoint, attempts to regulate the Internet are basically the same as trying to disrupt it; it’s simply not a technology which was designed to be regulated.

Sometimes it can be a daunting task to keep up with computer security best practices, especially when it comes to prevention. There is an almost unlimited amount of things to take into account, not to mention significant decisions on which risks you need to address and which aren’t worth the effort. In addition, many different people have many different ideas about what’s important when it comes to baseline mitigation. This may explain why there are so many sources on the topic, often with different core focuses in mind. For example, Cisco’s Network Security Baseline is geared towards networking configuration, while the PCI-DSS regulations are focused on the technology surrounding credit /debit cards. The truth is that no one set of general rules will ever be ideal for all scenarios; in most cases, the best-fitting strategy would be a custom solution.

However, even an imperfect solution can be useful. This week I came across this list of 35 general mitigation strategies suggested by the Australian DSD (they’re sorta like the NSA). Many of these paint with a wide brush (patch all the things!), but some are directed at specific applications of technology and software. The approach is very proactive in targeting the most widely used components of modern attack vectors. On their website, DSD makes the claim that implementing the top 4 suggested strategies would have prevented 85% of the incidents they responded to in 2010. A bold claim (assisted by wide scopes):

1. Update and patch Adobe products, Microsoft products, and Java.
2. Update and patch your OS
3. Be stingy with administrator/superuser access
4. Whitelist your programs

I’m sure that taking these steps can eliminate much of the low hanging fruit, and doing all 35 would probably eliminate even more. But even if all 35 are not ideal for every scenario, it’s still all-around decent computer security advice. These strategies can be a great reference source when fleshing out a custom security policy for mitigating attacks. The rest of the list can be found here (pdf).

“I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I
I took the one less traveled by,
And that has made all the difference.”
(excerpt from “The Road Not Taken” by Robert Frost)

DHS and MITRE had a big announcement yesterday. MITRE has developed a new system for scoring weaknesses in applications, as well as for combining that score with “business value context” to produce a risk estimate. Overall, the work is interesting, though perhaps more from an academic perspective than anything else. What I find interesting is that we’re going back down this road again (“trust” evaluation), which seems like it will inevitably lead to another game-able system.

(more…)

It was recently announced that Electronic Health Records (EHR) are in use in all military hospitals. Granted the article is mostly marketing screed for one company, but it still represents a big step. Outside of the Department of Defense (DoD), this probably doesn’t seem like a very big deal. Inside the DoD, it’s HUGE. This is the culmination of years of work and millions, possibly billions, of dollars spent. It’s an important step in improving the health care for Wounded Warriors.

It also sets the stage for wider adoption of EHR in the private sector. But there are reasons to be concerned about this, of course. There are few, if any, pieces of information more intrinsically private and personal than one’s medical records. And while making these records available in an electronic format offers great advantage in medical care, it opens up great risk of compromise.

(more…)

As you’ve doubtless heard, Sony’s PlayStation Network has been down for several days now. The exact cause of this outage, being apparently affected by hackers of some stripe, is doubtless worth investigating. However, since those details haven’t been fully divulged yet, it’s best to wait on that front.

But this brings to light an increasing problem: the erosion of standalone functionality. PSN customers have not been able to access online content since April 20th. This is, of course, to be expected – if you shut off the network, the network is not available. Unfortunately, this extends to content which isn’t actually hosted on Sony’s network, since PlayStations use the PSN to connect to outside servers. Still, though, not surprising.

Vexingly, however, a certain amount of offline content has also been rendered unavailable, specifically several Capcom games which apparently need internet connection even for single-player mode. This seems to be an increasing trend in the software industry, in games of course, but in other software as well. Even software which has no need to be online, such as a word processing suite, increasingly needs to authenticate with a server in order to install. In fact, you might have noticed that most builds of MS Windows have just such an authentication requirement. And this is continuing to the next level: the Google CR-48 laptop as almost no functionality without an internet connection. Woe betide the user who truly does not want to ever connect a machine to the Internet!

But why would someone want to keep their computer offline?

Well, security, for one. The “airwall” remains the strongest form of security available; no code can ever bridge the gap of a true lack of connection. This isn’t solely the province of super secret government facilities, after all: medical facilities, industrial applications, and numerous other facilities can achieve higher security by dint of simply not connecting machines to the Internet when it is not needed.

Some may not be able to achieve an Internet connection, either due to cost or lack of infrastructure. As amazing as it may seem in 2011, Internet access is not available everywhere, nor to everyone.

But the most important reason is highlighted by this PSN debacle: why should Internet access be necessary? The Internet is a powerful, pervasive tool – but it’s not the end-all of the computing experience, and even now there’s no reason that a computer should be rendered a paperweight by simple lack of connection.

While the software industry continues to make strides in the area of security and data protection, the hardware industry shouldn’t be underestimated. With the announcement of storage devices like Toshiba’s MK-61GSYG hard disk drives, it may only be a matter of time before we see even more creative security features for hardware (due, in part, to industry-wide adoption of standards). Toshiba’s harddrive comes with some interesting security tricks, including the ability to configure the disk to erase itself when connected to an unauthorized host, and the ability for the drive to self-encrypt without relying on the host computer’s operating system for cryptographic operations.

Most of the features are drawn from the standards found in the Opal Security Subsystem Class (SSC) (pdf). The SSC is, in turn, based on the TCG Storage Architecture Core Specification. TCG is the same company behind the TPM platform standard, which was designed to let a system create and operate a trusted subenvironment from within an untrusted environment. The TPM platform still receives a fair amount of criticism for privacy issues and the potential for abuse.

A similar approach is used for some OPAL-compliant storage devices: dedicated on-board hardware that can handle a range of specialized operations (maintenance, authentication, cryptography) independently. The result is hardware like the MK-61GSYG, which probably meets many storage security requirements right out of the box. Although much can be said of the controversy that can surrounds newer standards, they can certainly provide a welcome stepping stone for innovation.

Last week there was talk of an information breach affecting customers of several large corporations, whereby names and email addresses may have been leaked through a marketing company (Epsilon).

Even without knowing all of the minute details, there are some important things to take away from this:

• Large pools of consolidated personally identifiable information are huge targets for would-be attackers
• Those you trust with your trusted data might not be as careful with it as you’d like them to be (applies to both customers and companies)

But, although there is much to be said of the risk we all take when we share private data, perhaps the bigger issue is the fact that companies hound you for your personal information in the first place. I can *maybe* understand a bank or financial institution needing to know a reference phone number or an email address to send you account information. But Walgreens, Kroger, Eddie Bauer; do they *really* need my personal contact info?

I once had an airport kiosk salesperson to verbally question whether or not I gave him my real phone number on the questionnaire that I filled out to get a “free” prize. I fraudulently reassured him that the last 4 digits were “3210″, and I half-expected him to whip out his phone and double-check.

But not every company is out to spam you to death. And I’m sure there are many people who don’t mind being marketed to (especially by their favorite brands). But for those of us who are asked to give up our email addy at the checkout counter, what can we do to shield ourselves from the inevitable mishandling of information we might not even want to share?

Far be it from me to suggest that *other* people willingly give out inaccurate information, but I regularly switch my phone number digits around and give out the wrong domain for my email (apologizes to my hotmail address twin). Even without resorting to harmless chicanery, there are things we can do to protect some of our important data. For example, disposable email addresses are great for keeping spam out of your real inbox, and have the added benefit of being valued lower by attackers than, say, a business or government account. After all, who targets mailinator accounts? Or, if you have the technical chops, an option may be to sign up with a call-forwarding service (like Google Voice) in order to cloak your actual phone number.

In other words, consider giving out your personal information on a need-to-know basis. Even then, we may have fewer options when it comes to protecting data a company creates in-house about its own customers, or the details associated with payment card purchases. But then again, that’s why we have standards like HIPAA and PCI-DSS…

Greetings from the 2011 RSA Conference in rainy San Francisco, CA. Yesterday I attended the opening keynotes of the conference, and a certain statement by RSA’s Art Coviello caught my ear and needs some further discussion.

The conference opened with a fantastic video called “Giants Among Us” which provided a brief chronicle of the rise of public key cryptography, from Martin Hellman, Whitfield Diffie, and Ralph Merkel, to Ron Rivest, Adi Shamir, and Leonard Adelman. It was well produced and is worth a watch. Note: updated link to HD version.

Art Coviello then came out and started his talk with a brief history of the 20 years of the RSA Conference, which was entertaining in its own right. He brought up classic confrontations, amusing talk titles, and showed the advance in both the number of talks and the amount of marketing over the years. During this session, Art showed a chart which displayed the number of talks about public key infrastructure (PKI) over the years.

Note: it turns out that 2001 really was the “Year of the PKI”, and it’s not always next year. This chart was a bit of an eye-opener, especially for me – a long time PKI evangelist. (No wonder those proposed talks aren’t being accepted!) At the conclusion of this discussion, Art made the following comment:

While smart cards and PKI never achieved the ubiquity we thought, they’ll continue to play a major role in security, especially PKI in cloud computing…

Here is where I definitely need to disagree. There is a difference between ubiquity and commodity. PKI’s ubiquity cannot be measured by the number of product vendors on the show floor, or talks offered at the conference – it can only be measured by the deployment and use of actual X.509 certificates throughout the world.

Some examples: If you have used SSL or TLS, you have used a PKI. If you have used a web service, such as SAML, you have used a PKI. If you have used a virtual private network (VPN) solution, you have used a PKI. If you have used Microsoft Remote Desktop, Active Directory, or any number of other crucial back-end services which use public key cryptography, you have used a PKI.

PKI is ubiquitous. It just isn’t getting in the way as much anymore.

As you might have heard, the IPcalypse is nigh. Okay, maybe you haven’t heard. The IPcalypse refers to the sale of the last IPv4 addresses on the open market. We’re projected to run out within the next few days. How will this affect you?

Odds are it won’t. Not in the short term, at any rate. Imagine if the post office announced that they’d run out of street addresses. All of the existing houses would be fine, and still be able to receive mail. New houses wouldn’t get addresses, though, and would be unable to send or receive mail. Running out of IPv4 addresses is like that.

Of course, it’s somewhat more complicated. Whereas you can still build a house without a postal address, still live there, still have people come over – well, imagine if you need an address to access the road. Without an IP address, a computer is cut off from the internet. It can neither send nor receive data; it’s just a standalone device.

But there remain options. Plenty of them, in fact.

(more…)