TSA's Misstep

http://www.technewsworld.com/story/57281.html

So what's new, right?! This expression is becoming very common nowadays, from completely unforgivable sins such as not securing hardware to exposing sensitive data to the general public on an uncontrolled/unmoderated website (the Agriculture department comes to mind).

Let's analyze for a second how such a mishap could occur. Places such as the Los Alamos lab - famous for disappearing drives and dead-end investigations, don't seem to have a clue as to what to do and look for when a critical piece of hardware goes poof!

Lifecycle of a disk (bought separately, and assuming formal processes exist):
a. Requisition for purchase
b. Approval
c. Order
d. Delivery
e. Verification
f. Change Management process approval
g. Implementation/installation
h. Usage
i. Fault - Return to sender
j. EoL

Worker W requests Manager M for extra space and submits requisition, M approves it and sends it to Purchasing for placing the order.
Disk comes through, is verified by the appropriate personnel, and the CM team authorizes the installation of the disk (might involve downtime, reboot etc).
IT installs the disk and brings it online so users can store twenty-thousand copies of the same document so they run out of space way before the projected date and then place more orders.

Say an error crops up on this new disk, which by now has a lot of data, IT will be asked to look into it. IT will try to backup the data to another disk and try to fix it. In the meantime, since most workers have filled up this new backup disk and don't have any problems with it, they're likely to push for IT to delay installing the new disk, which has been fixed by now.

So, IT just waits around, and eventually something happens that causes them to lose track of it. This 'something' is the most dangerous aspect of IT and security because nobody knows what it is (and that's why it's called 'something'). It could be an employee with malicious intent to an ID thief to an innocent misplacing to out and out loss of the disk beyond recovery. This becomes much more of an issue if the disk is to be shipped elsewhere (ironically, for safekeeping or backup) and nobody really knows whether the destination received it, or whether they got the right material, or whether the disk was even sent!

Anyway, all through the steps above, there is no TRACKING of the material. If there were a CMDB in place, then much of this could have been part of its DB and then could be made a traceable and trackale entity.

Then, when a disk went missing, all one would have to do is search for the part number/brand/custom id/tracking number/dept id/destination -- you get the idea -- and take further action. The point is that not much is unknown at that time. Auditing, which should come in between 'h' and 'i' is the one process that people love to hate, but one which may save their (and our) lives one day. As long as regular auditing is done using the CMDB as an authoritative source of existing inventory, one can be assured that such 'issues' won't be so common as one's less likely to be lackadaisical when an audit is due.

Since most people don't even know what a CMDB is, it's going to be hard to convince them or educate them on the importance of such a database. The root problem thus lies in education and awareness. Get familiar with ITIL!

Security is all about education, training, and awareness. As Fox Mulder put it, TRUST NO ONE. This doesn't mean you incur the wrath of your boss for asking him 20 questions on why he wants to see your code, but that anyone that's not in your immediate circle of trust (something like PKI) should not be privy to your sensitive data. The idea is Need to Know comes before everything else.

Coming back to this intriguing case of the missing disk, here's how I'd do it (all of these trackable details such as tracking number etc would go into the CMDB):

a. Requisition generated by user (tracking number (tn) 1234)
b. Approval by manager (tn, approval id (aid) A45)
c. Order (tn, aid, order number (on) O858)
d. Delivery (tn, aid, on, delivery date (dd) 05/08/2007, shipper id (sid), dept id (did))
e. Verification (tn, aid, on, dd, sid, deptid, verification id (vid))
f. CM approval (tn, aid, on, dd, sid, deptid, vid, chg mgr approval id (cmid))
g. Ticket to install/installation (tn, aid, on, dd, sid, deptid, vid, cmid, iticket)
h. Usage
i. Fault (tn, aid, on, dd, sid, deptid, vid, cmid, fticket)
j. Shipping (tn, aid, on, dd, sid, deptid, vid, cmid, fticket(if fault), rticket (if request to ship), sid, sender deptid, receiver deptid, slaid (service level agreement id))
k. EoL

As you can see, everything here can be traced to the finest level - nothing can escape scrutiny, and accountability is preserved.

As for data structure, when I say verification id, the id should point to a table that contains at least the original requisition id, the id of the person performing the verification, the outcome, destination dept, contact who will pick up the disk, and anything else that may matter).

I realize it sounds like overkill, but try facing 10,000 workers after 'losing' their most precious and sensitive information. Their stares alone will jolt you into becoming an evangelist for data safety, if the govt/sanctions/bad reputation don't get there first.

Be safe!