I didn’t plan on writing about the DHS blowing up a power generator on CNN, but I’m in my hotel room in Vegas waiting for a conference call and it’s all over the darn TV. Martin and Amrit also talked about it, and I hate to be late to a party.

That little video has started an uproar. Based on the press coverage you’ve got raving paranoids on one side, and those in absolute denial on the other. We’re already seeing accusations that it was all just staged to get some funding.

I’ve written about SCADA (the systems used to control power grids and other real-world infrastructure like manufacturing systems) for a while now. I’ve written about it here on the blog, and authored two research notes with my past employer that didn’t make me too popular in certain circles. I’ve talked with a ton of people on these issues, researched the standards and technologies, and my conclusion is that some of our networks are definitely vulnerable. The problem isn’t so bad we should panic, but we definitely need to increase the resources used to defend the power grid and other critical infrastructure.

SCADA stands for Supervisory Control And Data Acquisition. These are the systems used to supervise physical things, like power switches or those fascinating mechanical doohickies you always see on the Discovery Channel making other doohickies (or beer bottles). They’ve been around for a very long time and run on technologies that have nothing to do with the Internet. At least they used to.

Over the last decade or so, especially the past five years, we’ve seen some changes in these process control networks. The first shift was starting to use commodity hardware and software, the same technology you use at work and home, instead of the proprietary SCADA stuff. Some of these things were O L D old, inefficient, and took special skill to maintain. It’s a lot more efficient for a vendor to just build on the technology we all use every day; running special software on regular hardware and operating systems.

Sounds great, except as anyone reading this blog knows there are plenty of vulnerabilities in all that regular hardware and software. Sure, there were probably vulnerabilities in SCADA stuff (we know for a fact there were), but it’s not like every pimply faced teenage hacker in the world knew about them. A lot of new SCADA controllers and servers run on Microsoft Windows. Nothing against Microsoft, but Windows isn’t exactly known as a vulnerability free platform. Worse yet, some of these systems are so specialized that you’re not allowed to patch them- the vendor has to handle any software updates themselves, and they’re not always the most timely of folks. Thus we are now running our power plants and beer bottling facilities on stuff that’s on the same software all the little script kiddies can slice through, and we can’t even patch the darn things. I can probably live without power, but definitely not the beer. I brew at home, but that takes weeks to months before you can drink it, and our stash definitely won’t last that long. Especially without any TV.

Back to SCADA. Most of these networks were historically isolated- they were around long before the Internet and didn’t connect to it. At least before trend number two, called “convergence”. As utilities and manufacturing moved onto commodity hardware and software, they also started using more and more IT to run the business side of things. And the engineers running the electric lifeblood of our nation want to check email just as often as the rest of us. And they have a computer sitting in front of them all day. Is anyone surprised they started combining the business side of the network with the process control side? Aside from keeping engineers happy with chain letters and bad jokes, the power companies could start pulling billing and performance information right from the process control side to the business side.

They merged the networks. Not everyone, but far more companies than you probably think.

I know what you’re all thinking right now, because this *is* Securosis, and we’re all somewhat paranoid and cynical. We’re now running everything on standard platforms, on standard networks, with bored engineers surfing porn and reading junk email on the overnight shift.

Yeah, that’s what I thought, and it’s why I wrote the research.

This isn’t fantasy; we have a number of real world cases where this broke real world things. During the Slammer virus a safety system at a nuclear power plant went down. Trains in Sydney stopped running due to the Sasser virus. Blaster was a contributing factor to the big Northeast power outage a few years ago because it bogged down the systems the engineers used to communicate with each other and monitor systems (rumor has it). I once had a private meeting in a foreign country that admitted hackers had gained access to the train control system on multiple occasions and could control the trains.

Thus our infrastructure is vulnerable in three ways:

1. A worm, virus, or other flaw saturating network traffic and breaking the communications between the SCADA systems.
2. A worm, virus, or other attack that takes down SCADA systems by crashing or exploiting common, non-SCADA, parts of the system.
3. Direct attack on the SCADA systems, using the Internet as a vector

Some of these networks are now so messed up that you can’t even run a vulnerability scan on them without crashing things.

Bad stuff, but all hope isn’t lost. Not everyone connects their systems together like this. Some organizations use air gaps (totally separate, isolated networks), virtual air gaps (connected, but an isolated one-way connection), or air-locks (a term I created to describe two separate networks with a very controlled, secure system in the middle to exchange information both ways, not network traffic). NERC, the industry body for the power networks, created a pretty good standard (CIP, Critical Infrastructure Protection) for securing these networks that went into effect last year. When I talk to power guys these days about network separation, I don’t get nearly the strange looks I did five years ago.

Another thing in our favor is that to cause serious damage like we saw in the video, you really need to know what you’re doing. You have to gain access to the network, disable safeties, and know exactly what to do.

Well, more bad news. I’m not worried about Joe Hacker at Starbucks or whatever they use for Internet cafes in Russia (Starbucks?) taking down the North American power grid. But it’s very clear that foreign nations have the expertise to do this, especially over in China where they seem to be having all sorts of fun on our networks. Terrorists? They’re better off just blowing up a few major transformers. That will take out major parts of the grid, might blow up some generators (years ago the one at the University of Colorado blew up during a big blackout), and those transformers are both costly and may take years to replace. Besides, terrorists are blood-obsessed psychotics, despite their threats to attack our economy and infrastructure.

In summary we are definitely vulnerable to just the right kind of attack, but it’s a problem we can get our arms around and solve with a little investment and common sense. Not everything is vulnerable yet, and we’re early enough on the convergence trend that we can still stop and put the right security precautions in place.

I’m glad that video hit the news; maybe we’ll get the right amount of dollars in the right places so we can take this one off the table.

Unless the bad guys just get jobs at the power plants and flip switches during the midnight shift.

Not that I’m paranoid or anything.

H D Moore got an iPhone. This is both good news and bad news for Apple.

The bad news is that once some remote vulnerabilities appear (including clientside vulns), and get coded into exploits, the Metasploit Framework is ready for them with some iPhone-specific payloads. Let the iPhone pwnage begin.

The good news is that I think this will help keep the iPhone more secure. There will be clear motivation to keep this thing patched, and researchers and Apple’s own developers can more easily demonstrate the exploitability of any particular vulnerabilities.

And the really good news is you can update your iPhone. Easily. This is a first for the mobile phone market and a clear security advantage. Even if Apple makes mistakes (which they have and will), they can fix them far more easily than other mobile phone manufacturers.

Richard Bejtlich, commenting on a Marcus Ranum article, said:

“Continuing to function” is an interesting concept. The reason the “Internet” hasn’t been destroyed by terrorists, organized crime, or others is that doing so would cut off a major communication and funding resource. Criminals and other adversaries have a distinct interest in keeping computing infrastructure working just well enough to exploit it.

I have to disagree here. While there are a lot of smart bad guys just out for a little profit, there are plenty of malicious psychos looking to cause damage. When I did physical security and worked as a paramedic there was a distinct difference between profit-driven crime and ego-driven crime, even in the same criminal act. Ego crimes, ranging from vandalism to spousal abuse, originate in flaws of character where logic and self-preservation don’t necessarily play a role. Or sometimes they’re just fueled by testostahol, the powerful substance created when alcohol and testosterone mix in a juvenile male’s bloodstream.

There are plenty of people who would bring the Internet down either to show they could, or to damage society out of some twisted internal motivation. The root DNS servers are constantly under attack, and not just because someone thinks they can make a buck doing it.

Marcus said,

Will the future be more secure? It’ll be just as insecure as it possibly can, while still continuing to function. Just like it is today.

Not because the bad guys want it that way, but because once crime crosses the threshold where society can’t function at some arbitrary level of efficiency or safety, the populace and governments wake up and take action to preserve our quality of life.

There really isn’t much motivation to invest in security that’s more than “good enough” to keep things running. We all have acceptable losses and only act when those are exceeded.

I get in early Wednesday morning and head home Friday. If you want to meet up, drop me a line at rmogull@securosis.com.

I think Martin and I have definitively proven that recording a podcast at 8 am isn’t the smartest idea in the world. Sure, the content is still there, but there are quite a few more “ums” and “ahs” than usual. Martin had to run to San Francisco today, and we had to push recording from last night due to a stray cat problem at my house.

Not to worry, we still managed to talk about a little security. I probably went a little overkill and used Core Impact to help me work out some of my home network issues and reconfigure my wireless design. I’m having a little trouble identifying all my devices on the network and am too lazy to just turn them off and figure out that way. Once we finished our personal geek-rambling, we finally dug into some honest to goodness security issues.

Finally, congrats to Martin, who is both gainfully employed again and the proud daddy of a new XBox 360.

Show notes:

• Rich’s blog entry on TD Ameritrade
• Hacking Sermo.com, the social network for doctors parts 1 & 2
• Brian Krebs: Is Cyber crime really the FBI’s #3 priority?
• PCI Extends its reach to application security
• Tonight’s music: Dragons by The Switch

Network Security Podcast, Episode 78

Time: 53:01

I never meant to become that “data security” dude.

Back when I first transitioned from a consultant to an analyst I was given a hodgepodge of technologies to cover. Since I’d been a DBA and programmer I picked up database security. No one was covering encryption, so that fell in my lap. We’d recently lost the person covering forensics and acceptable use, so I ended up with that as well. This was all about 5 or so years ago, and at the time it seemed like a random collection of technologies.

Then I started noticing some similarities and overlap. Clients would call in to ask about these different technologies yet they were all often working on solving the same problems. At first it was defending against, “the insider threat”, but then it started to transition into protecting data/content. I started digging in and realized that although we in security have spent years talking about insider threats and protecting data, our advice was typically little more than hand waving or “encryption”, without really understanding what encryption can and cannot protect against.

I decided to try and pull this all together into a framework and my first pass was the Data Security Hierarchy. While a good start at figuring out the various layers used to protect data, it really doesn’t help you figure out when to apply controls and which ones work best under which circumstances. It was little more than an interesting conglomeration of generic technology layers that isn’t actually very practical in designing security controls.

Thus I’m proud to announce my next attempt- the Data Security Lifecycle. This time I’ve broken security controls out based on the lifecycle stage of the data. From creation to destruction, the Data Security Lifecycle shows which controls should apply at which phase. This provides more practical guidance and helps prioritize data security technology investments.

This diagram is the high-level controls view. While in some cases these controls map directly to a specific technology, in other cases a single control may map to multiple technologies. Future posts will map specific technologies to specific controls, so don’t beat me up over the genericism quite yet. This view represents both structured and unstructured data; future posts will break them out separately since you can’t treat a database the same as a Word document. Finally, this view does not prioritize controls based on data classification. Again, that’s fodder for a future post. Yep, I’ve got a heck of a lot to write about here and will be breaking it out into manageable chunks.

In developing the Data Security Lifecycle I reviewed many of the information lifecycles out there, and paid particular attention to Information Lifecycle Management (ILM). I didn’t feel that ILM mapped as well as we needed to the security domain so I decided to borrow elements of it, but in the end designed a more security-specific lifecycle. The stages are:

1. Create: This is probably better named Create/Update since it applies to creating or changing a data/content element, not just a document or database. Creation is defined as generation of new digital content, either structured or unstructured. In this phase we classify the information and determine appropriate rights. Sounds hard, but in many cases this will be performed by technology or default classification and rights applied based on point of origin.
2. Store: Storing is the act committing the digital data to structured or unstructured storage (database vs. files). Here we map the classification and rights to security controls, including access controls, encryption and rights management. I include certain database controls like labeling in rights management — not just DRM. Controls at this stage also apply to managing content in our storage repositories, such as using content discovery to ensure that data is in approved/appropriate repositories.
3. Use: These controls apply to data at the point of use- typically a user’s PC or an application. We include both detective controls like activity monitoring, and preventative controls like rights management. Logical controls are typically applied in databases and applications. I’ve also lumped in application security although that’s a massive domain on its own and mostly outside the scope of this lifecycle.
4. Share: These controls apply as we exchange data between users, customers, and partners. This again includes a mix of detective and preventative controls, such as DLP/CMF/CMP, encryption for secure exchange of data, and (again) logical controls and application security.
5. Archive: In this phase data leaves active use and enters long-term storage. We’ll use a combination of encryption and asset management to protect the data and ensure its availability.
6. Destroy: Not all data is permanently retired, but when it is we need to delete it securely and use tools like content discovery to track down any lingering copies.

For you ILM geeks, here’s a mapping of the Data Security Lifecycle phases to ILM:

All of this is a work in progress. Over the next few posts I’ll start mapping these high level controls to specific technologies (distinguishing between structured and unstructured data) and prioritize based on classification level. Not all the technologies we’ll be discussing are the most mature in the world, so we’ll also prioritize a little bit based on what’s effective and practical in today’s markets.

I don’t consider this anything revolutionary; it’s merely a logical progression, as we see improvements in both the available technologies and our understanding of how data is compromised. I’m trying to present it in an organized big picture. It’s one of those funny things that seems to take endless hours of thought and doodling to build a simple looking diagram that doesn’t look like much. Oh well.

This is still all under development and any feedback (preferably in the comments) is appreciated. Eventually I’d like to use this as a basis for a comprehensive book on data security, but that’s still a little ways out unless one of you fine readers is independently wealthy and would like to support my lifestyle while I write full-time.

I always wonder what I’ll wake up to on a Monday morning.

Today it was a nice new cross-site scripting (XSS) vulnerability over in Google. The details are over at bedford. org (link broken since it’s a little risky), and the focus is on Google Mail.

Bedford has three proofs of concept up. The first exploits Blogspot polls, the second Gmail contacts, and the third forwards all your incoming mail to Bedford.

I tested them out, and while the contacts one didn’t work for me in a quick test, the forward definitely worked. This means anyone can send you an email or embed code in their web page that will then forward all your Google mail to an address of their choosing.

This isn’t a particularly stealthy exploit- if you go into your Gmail settings you can check if your account is forwarding. Just click on settings, Forwarding and POP, and make sure Disable forwarding is checked (as in this screenshot).

The proof of concept was posted on September 24th, so it’s not like this is the first day it’s public Umm… I should have coffee and check the calendar before I blog; that’s today. And while my little advice will help with the forwarding problem, the base code looks like it can do pretty much anything it wants with your Google Mail account, so there’s all sorts of other possible nastiness.

Some people are recommending FireFox with NoScript. Personally, I suggest you just log out of Gmail with your web browser and set up your mail client to access Gmail directly (no browser access).

All of these are crappy workarounds until Google plugs the hole.

Update: I shouldn’t blog before my first cup of coffee. If you’re going to enable POP access, you need to first log in from a “clean” browser, change your password, then set up encrypted POP access. Google’s instructions for this are pretty easy, and seriously, don’t skip that changing your password step.

(Thanks to Maynor/Errata for the heads up).

Sheesh… just when you think they’re over the hump, more details leak on the TD Ameritrade breach and they aren’t looking quite so competent anymore.

Network World has a good article up summarizing the latest developments. A few tidbits stand out:

The Ameritrade spokeswoman says the company believes no Social Security numbers have been taken because the only known illicit activity traceable to the breaches is spam, not identity theft.

There’s a word for statements like this… bullshit! Just because they haven’t traced any identity theft or other fraud to the SSNs in their database doesn’t mean the numbers aren’t sitting on some bad guy’s hard drive someplace. If they determined that SSNs are not at risk because the specific malicious software involved was analyzed and limited itself to email, then that’s one thing. But saying “nothing bad has happened so far, so nothing bad will ever happen” is stupid.

Folks, time for a reminder. This is all Crisis Communications 101- as history has shown, the best way to defend your reputations in a major incident is to admit the failing, spare nothing to protect your customers, and act as openly and honestly as possible. Otherwise we wouldn’t have seen a bottle of Tylenol on a store shelf since the 1980’s.

This:

The company says it will sign its customers up for the service on an exception basis -meaning they don’t automatically get it - but it doesn’t advertise this option in any of the literature it has put out concerning the data compromise.

is not putting your customers first.

The rest of us should learn from this; TD Ameritrade is now suffering more negative publicity than if they had come clean from the start.

I’ve moved our little poll on this to the sidebar, and will post the results on Monday. I’m starting to think it might be something other than SQL injection…

I’m probably going to swing out to Vegas for a day or two, but haven’t figured out what days yet.

If you’re going and want to meet up, drop me a line in the comments or at rmogull@securosis.com.

Cutaway has a good post up today over at Security Ripcord. In it, he suggests that Microsoft should… well, I’ll let him say it:

Here is my solution: Microsoft needs to come up with a Central Update Console that software and driver developers can hook to configure automatic updates. They already provide this type of feature through the “Add/Remove Programs” console. Good developers utilize this to help users and administrators manage the software that is installed on their systems. How hard would it be to come up with a solution that other developers could hook to help with centralizing the management of updates and provide a significant positive impact on the overall security of every computer on the Interweb? Although the design, development, testing, implementation, and maintenance of this project would be challenging, I am willing to be that this would be a small project in the grand scheme of Microsoft OS development. They don’t need to take every software vendor into consideration, they just need to come up with one method all of them could use.

This is something I’ve actually put some thought into (and not just because Cutaway and I talked about it a couple weeks ago), but I don’t think it can work. At least not today.

Managing vulnerabilities and patches is a huge issue, with a moderately sized third party market just to deal with it. While Microsoft provides patches for their own software only (with few exceptions, like a recent ATI driver update), they don’t provide patches for non-Microsoft software. I think this is for two reasons that I don’t expect to change anytime soon.

1. Antitrust- there’s an entire market dedicated to vulnerability and patch management. MS can’t step in an include this in the OS, however useful an idea, without having to face antitrust accusations. Due to past mistakes, they are often restricted from including features other OS vendors don’t blink an eye at. Take a look at all the whining by Symantec and McAfee over Patchguard.
2. Liability- it doesn’t matter how many warnings and disclaimers MS puts on the darn thing; the first time a bad third-party patch propagates through a Microsoft central patch console and blows up systems (which is inevitable), the world will cry havoc and let slip the dogs of alt.ms.sucks- and at least a few lawyers, wanting a piece of the MS pot of valuation.

On the enterprise side this isn’t as much of an issue since most organizations don’t use the update function built into Windows (although they do use WSUS (Windows Software Update Server).

Consumers, on the other hand, rely heavily on Microsoft for their updates and some sort of central service for third party patches could really help keep their systems current. Especially for device drivers; while applications can build in their own update functions and check whenever they’re used, device drivers represent a huge class of vulnerability that even most enterprises don’t pay enough attention to.

Also, as software gets more and more intermingled the risk of relying on application launch to check for patches becomes a problem. Components can represent an exploit risk through a web browser or a virus, even if you haven’t launched the application in a long time. Today, vendors manage this by ignoring it or installing YAASTS (Yet Another Annoying System Tray Service) that runs constantly, draining your system resources.

Thus I think Cutaway’s idea of a central patch service could provide a lot of value and help improve security. No argument there. But it represents a risk to Microsoft that I just don’t think the product managers, never mind the lawyers, will let them take.