Research

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: A worm, virus, or other flaw saturating network traffic and breaking the communications between the SCADA systems. A worm, virus, or other attack that takes down SCADA systems by crashing or exploiting common, non-SCADA, parts of the system. 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

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. Share:

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. Share:

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

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 Share:

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: 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. 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. 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. 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. 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. 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. Share:

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). Share:

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… Share:

You can always smell desperation. It has a certain… quality that gently waifs into the nasal cavity, tickling those very nerves that are too oft neglected in our sanitary society. You know, the same ones that pick up the odor of sewer crap. What’s odd is that this smell is extruded not only by the truly desperate, but by those whose self esteem is so battered that they crave every bit of validation they can beg off the nearest passerby. It’s a strange dichotomy. When evaluating vendors and their chances of success, desperation isn’t always a clear indicator of their future. On one side we have the truly desperate, such as the vendor I worked with, who was quietly shopping around for a buyer and could only provide small school districts as references. On the other side was the bully; the successful startup who revelled in sending photos of their gear replacing a competitor’s on a rack. They eventually got bought for big money, but I suspect that marketing manager is blowing it all at a strip joint dropping twenties in the hopes the dancer will make eye contact and call him darling before strutting off stage with enough cash to solve the crisis in Darfur. Today, thanks to Alan Shimel, we see probably the most amusing act of desperation I’ve ever witnessed. One of his competitors, ForeScout, bought the Google AdWords for Alan’s name. Now, every time you search on Alan, the first thing that comes up is: Replacing Safe Access? www.forescout.com/counteract Get CounterACT – Clientless Network Access Control from ForeScout This is the security marketing equivalent of political push polling, but probably a lot less effective. Okay, it’s amusing, but ForeScout has probably given Alan one of the best sales tools he ever asked for. How hard do you think it will be for him to use this to his advantage in a competitive situation? Here’s a note to you marketing folks- take a look at sources like this Security Catalyst Forums thread on vendors. Acting like a used car salesman is a sure fire way to alienate a prospect. I hear this time after time. Yes, as Rothman tells us certain heavy handed tactics work, but if it smells like crap on a simple Google search, odds are the customer will figure out it’s crap. (For the record, I know nothing about ForeScout and haven’t ever worked with them; the product might be great for all I know) Share:

Fresh off today’s Daily Incite I saw that Raytheon acquired Oakley Networks. Oakley is a bit of a strange bird- it’s not really DLP, but they have some interesting monitoring technology that’s well suited for certain environments- especially the federal sector that Raytheon plays in so strongly. Oakley started with an endpoint monitoring tool that’s like keystroke capture on steroids (and centrally manageable), and then bought a network tool vendor for monitoring acceptable use on the wire. It doesn’t have the advanced content awareness of DLP, nor some of the integration required for the filtering and discovery sides, but that’s not really what it’s used for. DLP records only on violations; Oakley is better described as “user activity forensics” (it’s more than that, but that’s the closest bucket). I don’t expect to see Oakley/Raytheon break into the general enterprise market anytime soon, and I hope this ends the confusion of people lumping them into DLP (a lot of that’s their own fault from some decisions they’ve since moved past), but I think the Raytheon acquisition is reasonable and appropriate, and should be successful because of the federal focus. I don’t get to say that often about buyouts. Good luck to Tom and the guys… Share: