How hackers made minced meat of Department of Energy networks

http://arstechnica.com/security/2013/12/how-hackers-made-minced-meat-of-department-of-energy-networks/

by mud_dauber • 13 years ago

33 19 13 years ago

arstechnica.com

voltagex_• 13 years ago

Direct link to PDF of DOE report - http://energy.gov/sites/prod/files/2013/12/f5/IG-0900.pdf

ChuckMcM• 13 years ago

TL;DR version - if you don't apply security patches, or take basic precautions, you will get compromised.

It is sad that our government IT organizations are so poor, I would consider that a National Security threat much more than having the FBI help some whack job build a fake bomb so they can publicly "break up" a terror plot.

droidist22• 13 years ago

Did the fake bomb scenario actually happen? I'd be interested in reading about that.

reginaldjcooper2• 13 years ago

It sure did; http://www.theguardian.com/world/2013/dec/13/fbi-kansas-suic...

kevingadd• 13 years ago

http://www.cbsnews.com/news/fbi-terror-stings-entrapment-or-...

I've seen various stories about it. In a couple cases, evidence suggested that the FBI sought out unstable individuals and convinced them to engage in terror plots (instead of working their way into existing terror groups).

eli• 13 years ago

You can listen to a podcast about one instance http://www.thisamericanlife.org/radio-archives/episode/471/t...

pstuart• 13 years ago

A good read: http://www.rollingstone.com/politics/blogs/national-affairs/...

reginaldjcooper2• 13 years ago

One significant reason I don't want the government collecting all of my data is because they seem totally incapable of creating a secure system or even a system that operates properly.

kevinchen• 13 years ago

The NSA seems technically capable, though. (They seem to get the best of the best software engineers / IT people.) Not that it's good they have it, but at least they can keep it safe from outside attackers.

rdl• 13 years ago

The problem has actually gotten worse -- by acting like asshats and spying on US citizens (as well as a whole litany of other stupidity, like racist drug laws, ...), it's presumably a lot harder to recruit and retain great people for the less-sexy roles like IT/IA.

jrochkind1• 13 years ago

Chief among them is the fact that none of the 354 database tables containing social security numbers were encrypted. Using strong cryptography to protect such "at rest" PII has long been considered a best practice in government and corporate data security.

Really? Although I don't work in that field ('government and corporate data security', or generally anything where we have to deal with SSN's and such) -- that doesn't make a lot of sense to me. Encrypted database tables? I've never even heard of that. Can someone who does work in this domain tell us if this makes any sense at all, or translate this into what it actually means technically?

(On the other hand, the fact that 354 database tables existed with SSN's is a red flag in the first place, clearly. There's plenty of clear problems with what was described, I'm just curious about this alleged 'encrypted database table best practice')

jtchang• 13 years ago

In the payment industry there is the concept of PCI-DSS. It is basically a set of requirements regarding the handling of sensitive data. While a lot of it is just common sense some of it should be applied to any sensitive data that you are working with.

Encrypted database tables are not that common. More common is encryption of the whole disk or database using Oracle or some other software/hardware.

If you are storing full credit card #s it better be encrypted while the data is at rest.

6d0debc071• 13 years ago

Don't work in that area but

- http://en.wikipedia.org/wiki/Transparent_Data_Encryption

Apparently widely used enough to have support existing for it.

jerf• 13 years ago

It's possible to end up with access to a database via some mechanism without having access to the code that can decrypt the values. Perhaps you've stolen a backup, or exploited an SQL injection to get access to one of these tables, but without the decryption code it's useless (if the encryption itself is done correctly).

It's weak protection, because obtaining the database and obtaining the code are pretty highly correlated, but it can make sense in some situations. Obviously, the easier it is to obtain the unencrypted values, the less likely an attacker is to get stranded between the encrypted values and the decryption code. (i.e., an "encrypted partition" doesn't do much to defend against any remote attack because they'll all be using the readable mounted partition, a pervasive API layer that automatically decrypts things for user code is that much easier to accidentally use by the attacker as well, etc. In a weird way you want these fields to be as hard to use as possible, violating normal software engineering rules; every normal ease-of-use consideration is a hole.)

wiredfool• 13 years ago

Encrypting database tables is easy.

Key management so that you can do anything with the data is significantly harder, depending on your threat model.

scpotter• 13 years ago

I thought encryption of SSN was a well know basic practice, but other responses here have me wondering. Besides whole tables columns or individual elements (for non-normalized data) can also be encrypted. Some PII like name and address are rarely encrypted in my experience because it's low value, but I've worked on an anonymization project where all PII is stripped out after it's of no value to the organization.

Truly best practice: don't collect SSN unless you truly must have it, and never use it as a foreign key. The government is probably worst offender here, because there are really no consequences to individuals or organizations and tons of legacy systems.

dba7dba• 13 years ago

Who ultimately decides the patches cannot be added (for whatever reason)? It's ultimately the bean counters and managers beholden to them.

So I'm not really going to look down on the govt IT workers (or contractors).

How hackers made minced meat of Department of Energy networks

Related Stories