We've been sent all day long pointers to various media outlets regarding the leak of some blueprint for the choppers used as Marine One (they only use that call sign when the president is inside) at a government contractor (some claiming to know which it is), and all pointing to P2P software leaking it out on the Internet. Most -if not all- of these reports have some level of sensationalism to them.

As information security professionals, we need to look at incidents both in our own organization and others as a source to learn something. Especially learning from others is interesting as it avoids the hurt from failing ourselves.

Either we could be outraged over sensitive information being stored on a computer with Internet access that allows users to download and install unauthorized software. If we do this, we would likely end up going down the technological path (highly liked by vendors selling you stuff) to try to prevent installation of unauthorized software such as peer to peer software, or to detect information leaks and the like, but let's look if there's not something else in this story to learn.

First this is the US government, they work with relatively clear data classification levels and issue clearance to access certain levels to certain companies and/or individuals quite formally.

If this "sensitive" information was leaked, one of the unmentioned facts is how it was classified officially. The official classification (these levels exist in the US: UNCLASSIFIED, CONFIDENTIAL, SECRET and TOP SECRET) would indicate how big an issue it is. Similarly missing from public view is if that classification was appropriate for the content. Anybody having a copy should be able to instantly recognize the markings if it was classified.

The next step after classification is handling information that's been classified at a certain level. There are rules on how this should be done. And those rules are well established: NISPOM aka. DoD 5220.22-M is publicly available. NISPOM stands for "National Industrial Security Program Operating Manual".

And the final question is -if it went wrong- what consequences there should/could be -enforcement-.

From experience in the past, we tend to seek out a (number of) individual(s) and stick the blame on them. But we should also  -perhaps often- look at the organization itself as an group and maybe declare the group has missed the ball and try to fix it there without playing the all too easy blame game.

Anyway a good moment to review your data classification policies, your data handling and look how it's all enforced in your organization. When doing this, take care not to over-classify as that's very costly. Take care also not to mix low and highly classified information as it'll inevitably lead to errors and/or over-classification. Also look at declassification as a weapon against over-classification. It's after all only human nature to find our work important.

--
Swa Frantzen -- Section 66