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.