Night Dragon Reveals Shallow Defense in Depth in Oil & Gas Sector

Click to enlarge

Last month I did an initial post on the Night Dragon attacks, none too pleased that another one of these creatures was on the lose in our industry. Turns out my colleague, security ace Bruce Mayhew's been reading up and pondering on how the oil and gas companies that were targeted could have been caught with their collective guard so down. Here's Bruce and brace up - it gets a little technical:

What ever happened to defense in depth? Look at this modified security stack of defense mechanisms that could have prevented or at least gave earlier warning of the Night Dragon attack. Note: this is not a complete security stack, but a visualization of the many areas that were left unattended that led this to the success of this attack.

This post is only focusing on the portion of Night Dragon that allows the attackers to get RAT installed in the host environment: SQL injection. First off, parameterized database access stops SQL injection cold. And since we're talking about database, let's add in the concept of least privilege for the database functional account. Why was the database account setup to allow ANY access other than reading the database tables? If the application allowed writing of database data, then you would need read/write privileges. While either of these privileges would have potentially allowed for exploiting or corrupting the data, it should not have led to complete system compromise.

OK, let's assume the target application was using a technology that didn't allow for parameterized database access, the next logical defense would have been whitelist validation on the server. While not a fool proof strategy for preventing SQL injections it certainly would have limited the SQL injection attack vector. Now that we have server side whitelist validation, let's add in the exact same validation logic on the client or client-side validation. There is no direct security benefit to adding client-side validation other than I can then detect, on the server side, if the incoming data has been tampered with. If I have client and server-side validation and I receive input that does not validate on the server, the application is under attack. Time to take a defensive action like logging the attack (HTML Entity encoded) and log the user out.

Speaking of logging and logging the user out, was the user ever authenticated in the first place? Did we log that event? Are the logs being monitored? Why was an unauthenticated user given access to a critical asset like the database? There are so many relatively simple mechanisms that would have prevented this attack it makes me want to discuss security (or its complete lack) in the software development life cycle (SDLC). OK, that's another topic for another day.

If you don't completely understand Bruce's comments and guidance, I recommend you find someone on your staff who does and let them see this stat. Seems to me like Night Dragon should have never happened ... we made it far too easy for the attackers to get in and get whatever they wanted. My hopes are that headline news like this, and Stuxnet, Wikileaks and Aurora before it, energize utilities to upend the status quo and reconsider their approaches to cyber security.

Not all Smart Grid FUD is Created Equal

Depends were it comes from. In this case, I'd probably give the Center for Strategic and International Studies (CSIS) and McAfee the benefit of the doubt, pardon the pun. Even if there's the slightest grain of truth in this statement, it is cause for concern for our side:

Because of tight government controls, China's own grid was ranked in the survey as the best protected from cyber attack. A strict regime of compulsory government inspections compares to a third of British critical infrastructure providers who said their network had never been audited by authorities.

Here's the article in Britain's Telegraph, the CSIS link, and the recent McAfee report at the heart of all this.

Remember, even if this info makes you worried, the right thing to do with that anxiety is to channel it into positive action that can enhance the protection of our grid systems through improvements to policy, planning, process, technology, etc. It's a common refrain on this blog but I repeat again, good work rarely gets done in the fetal position.

Image credit: Stephen Brace on Flickr.com

I Don't Want to Talk about Night Dragon ...

... but looks like I have to. We're still digesting the energy sector cyber security implications of 2010's attacks on Google + 30 (confusingly named Operation Aurora), Stuxnet and Wikileaks, and now we've got another whopper.

Looks like energy sector, or more specifically, oil & gas companies were the primary target. Here's a short synopsis of the attack techniques used, which begin of course, with one of the most common (and easy to defend) attack vectors:

The attacks began with a SQL-injection technique, which compromised external web servers. Common hacking tools were then used to access intranets, giving attackers access to internal servers and desktops. Usernames and passwords were then harvested and after disabling Internet Explorer proxy settings, hackers were able to establish direct communication from infected machines to the Internet.

In my experience, oil & gas co's generally have more budget to spend on security protections than their electric utility brethren. So if they don't have their cyber houses in order yet against simple stuff like this, then it's quite likely that the same attacks would have breached electric co's as well.

Click HERE for a short article on this, and HERE for the more detailed report by McAfee.