
How hackers made minced meat of Department of Energy networks - mud_dauber
http://arstechnica.com/security/2013/12/how-hackers-made-minced-meat-of-department-of-energy-networks/
======
ChuckMcM
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.

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

~~~
kevingadd
[http://www.cbsnews.com/news/fbi-terror-stings-entrapment-
or-...](http://www.cbsnews.com/news/fbi-terror-stings-entrapment-or-
prevention/)

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

~~~
droidist2
Ahh ok, a little different than what I expected. When I read

> so they can publicly "break up" a terror plot

I thought it was purely to get publicity or instill fear in people while
getting good press for the FBI, rather than for a sting operation.

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

------
jrochkind1
> _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')

~~~
jerf
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.)

------
dba7dba
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).

