Don't Talk about the BOM

Names have been omitted to protect the guilty.

[Director] and [Division Chief] were walking through [major city] Airport discussing the bill of material for [facility] the directorate was engineering. A bill of material is a detailed sheet of all the parts needed for a project. It includes unit prices, quantities, part numbers from both manufacturer and vendor, etc. Since this was a big facility, this was a very large spreadsheet. Too big to actually print out; you had to have a laptop just to keep track of the whole sheet. Near the security checkpoint, the director says to division chief (or vice versa, reports vary), "Leave your laptop out and we'll work on the BOM on the plane."

They did not make their flight. When they were next allowed to communicate, every employee in the organization received a directive email, effective immediately and punitive, to scrub all references to "bill of material" and its acronym from all publications and replace with "List of Material (LOM)."

Now this story has to be true because it's been a decade since I've seen anyone use "bill of material." It's always "list of material" now.

Hack Stack

Retail giant Target was hacked late last year in a blow to holiday shoppers across the country.  Security investigators found out that the intrusion started with an HVAC contractor.  A reasonable computer user, denied access to others' secure systems, could ask themselves what an outside company would be doing with access like this.  Let's talk a bit about how large corporate systems are set up and how an attack can cascade like this through a supply chain.

Inter, Intra, and Extra

Most large companies' computer networks are set up in multiple zones.  The Internet zone holds customer-facing systems like company webpages, online shopping, and contact information.  These systems should only deal with low security issues like presenting product information or mailing addresses.  The Intranet zone is for internal use by employees.  A company's trouble ticketing system or employee computer-based training terminals are connected to this zone.  Extranet is the most complicated zone to manage and secure.  This is where partner companies connect to your systems for more access than the internet zone can provide without having employee level access on an intranet user.

Extra, Extra, Extra

In Target's case, Fazio Mechanical Services had access credentials to Target's systems to support billing and work contracts when Fazio was hired to perform work on the HVAC systems at Target stores in the Mid-Atlantic region. 
And, no, as user of Target's extranet, Fazio's credentials should not have enabled them to upload to or in any way make contact with any part of Target's point of sale terminals. 
Payment Card Industry (PCI) standards now come into play.  Companies which submit credit card payments are not required to build a separate network for payment and non-payment activities.  But outside users like contractors and vendors are required to use two-factor authentication to access a company's network. 

Targeted

Everyone is well aware of retail runner up Target and their recent hacking.  And this event couldn't have come at a worse time for them.  Their systems were compromised over Thanksgiving weekend, the traditional start of the holiday shopping season, and stayed pwned for several weeks.  Fortunately, they've plugged the holes and were able to continue on with their holiday sales season.
Meanwhile, banks around the country are taking steps to protect their customers' banking details.  Apparently, in light of lessons learned from major breaches like Heartland Payment Systems, many found it less expensive to just reissue thousands to millions of new cards to any customers who may or even might not be affected.  A major credit union here in Arizona is issuing new cards and numbers for 877 potentially compromised accounts.
While the stolen credit card information has already been put up for sale, Target insists that at least the PINs associated with debit cards were securely encrypted, specifically with Triple DES, or more properly, the Triple Data Encryption Algorithm, TDEA.
Triple DES is a block cipher, which means it encrypts blocks of data, 64 bits at a time, and does so in three passes, each with a different key based on the keying option used.  Data Encryption Standard (DES), with only a 56 bit key, is too weak to protect data against brute force attacks by modern hardware and has been removed as a standard.  Triple DES itself, by stacking up on the encryption with multiple keys, is considered secure enough against any practical attacks.  It has, however, been replaced in most applications with Advanced Encryption Standard (AES).
Target wasn't specific as to which keying option of Triple DES was being used, though they made it clear that they never had any of the keys.  Knowing which keying option was being employed could direct an attacker to a method of exploit.  Since Triple DES encrypts with key one, decrypts with key two, and then encrypts again with key three, the most secure option is that all three keys are different.  That usually isn't the way it's done in practice; typically the first and third key are the same.  Obviously, if there's only a single key being used three times, the encryption simplifies to a single round of DES and that compatibility is, in fact, why Triple DES does encrypt-decrypt-encrypt instead of three rounds of encrypt.
So what attacks are available?  Essentially a rainbow table attack.  We can only hope that the payment processor who held the keys held more that one.  Single key Triple DES is only DES and that could be broken in less that a day ten years ago.  That's a trivial brute force attack today.  Option two is the most commonly used method of implementing Triple DES and it's the one that encrypts with the first key, decrypts with a second key, then encrypts once more with the first key again.  The issue is that the plaintext being encrypted, all those PINs, is such a small domain.  PINs for debit cards are typically only four digits long.  At best, 32 bits or half a block.  Even worse, the Feistel algorithm that underpins DES and thus Triple DES operates on only a half block at a time.  The fluff and random bits that fill out the block might be irrelevant when decrypting stolen debit card PINs.  With such a limited domain, chosen plaintext and known plaintext attacks become available.  Insanely resource intensive, but available.
As a shout-out, my cryptography professor at the University of Maryland, Lawrence C Washington, along with Wade Trappe, also a Maryland professor at the time, literally wrote the book on cryptography.  I have the first edition.  Maybe I should've gotten it signed by the authors; I hear signed first editions are valuable.  Anyway, it's good to be a terrapin.  Let's Go Maryland!  Rah!  Rah!  Ra-ra-rah!

Security Credit

Bottom line up front the way the generals like it.  I take on vulnerability, all the additional threat is against me, and I assume all the risk.  Just to have my job.
Executive summary because the bosses who wear stars on their camouflage at the office like those, too.  There's a bit of utter stupidity to being a government employee.  In my job I am required to hold a government travel card and government passport.  That's right, I am required to increase my attack footprint [pdf] to have my job. 

Extra Credit

The points against the credit card are simple and straightforward enough for even a Treasury Department employee to understand.  Even though this card is For Official Use Only [pdf], the government has no financial risk in this credit card.  Externalities, they call it.  It's open credit on my report, not theirs.
It isn't common, but if the government doesn't settle travel expenses in a timely manner, it hurts my credit.  Just having it as an open account hurts my credit.  And not just the temptation for me to use or misuse the account as that linked article is concerned about.  It is yet another valid account for an attacker to break into and use for fraud.  The card itself, that stupid chit of plastic, is an identity document which can be counterfeit.  Speaking of misuse, done by me or anyone, it hurts my credit not my employer.  If some waiter skims the card I have to dispute the fraud or it's my credit rating that gets destroyed.  And yes, cards can and are misused in that very way even though they are clearly marked, "For Official Government Travel Only."
The entire program is adds vulnerability to me and I am required to assume all of the risk.  I've voiced this to management as an employee and a security professional but the program and the requirement for employment remain unchanged.

Papers, Please

Whether I travel outside the United States or not, frequently or not, I am required to hold an official government passport.  An identity document which can be misplaced or stolen between trips or while traveling.  And, just like with the credit cards, having a valid passport means an attacker can counterfeit a valid identity document for an attack.

Bottom's Up

Bottom line at the bottom the way the generals like it.  The entire pile of externalities, forcing the employee to assume all this additional risk as a condition of employment, should be redirected back to the organization.  

Don't Push the Red Button

I have a certain level of knowledge about the issues security professionals face and the incidents they cause.

First some background on this incident. A piece of hardware was reset and the encryption keys it contained were "zeroized". Then a message was sent out to the entire section informing them not only of the exploit but also underlying vulnerabilities which carry the risk of a denial of service. Because this incident report came through internal channels, it contains too much secure information to post here. There wouldn't be enough left after redaction. I will, however, discuss the incident in generic terms as a case study. Of course, the risk has been addressed.

Up front, let's address the sender of the message. The message was sent from the Information Management Office, a higher level function than over-titled secretary but that's a distinction that's easy to be confused over.  Not that the IMO is unauthorized to distribute information about incidents in the office, but as a general rule nobody should be distributing information on exploits or vulnerabilities. So that's who sent it, but where did it go? To a large office full of non-security job functions. Read that as "potential threats".

Let's move on to the content of the message. The message reveals a successful, yet inadvertent, exploit of a vulnerability with a security device in the office. It clearly describes how to "zeroize" the device and also how long to return to operation. Reading between the lines, additional indicators are revealed. There is a piece of critical equipment in an unsecured location. Anyone in the field should immediately ask what else is in that location. Keeping in mind that these devices will not pass traffic unless it's encrypted, the victim was under a complete denial of service. That operational state could be further exploited while personnel are distracted by recovery efforts.

As a security professional, how do you protect your office from this?

First, educate the threats. This incident was caused by an untrained user accidentally resetting the device. Flat out, every user needs to be properly trained to operate the equipment they have contact with. Also, educate your users about information security. Disclosing the incident could have deeper repercussions than the incident itself. An attacker should rightly assume that the risks here have been addressed and they should look for another vector. Or an attacker might just try to replicate the exploit anyway in the chance that it hasn't been addressed.

Secondly, lock up the vulnerabilities. I mean that literally. Lock up any hardware that doesn't require user contact. That's everything but the keyboard and mouse. And not just the physical hardware but also the software. Employ "least user privilege" by only giving users the amount of access they need for their jobs. An employee who's job description does not include "reset the encryption device" should not have access to that button.

Third, finish your risk assessment. Tally up the costs in dealing with your threats and vulnerabilities. Put it in real dollar amounts so you can do a quantitative comparison. In this case, a security container and user education. Now tally up the costs of a threat meeting a vulnerability to become an exploit. Again, in dollars out of the company budget. For this incident, it was one week of lost work by one office being unable to do secure business plus the cost of rekeying the encryption device. Finally, compare those dollar amounts. Assume the risk only if the cost of mitigation, in actual company money, is too high.