Layer 8

Deconstructing the VA debacle.

[Bloggiste note:  I originally lost most of this post in a deadly combination of senior moment and really short session timeout.  So now I’m faced with reconstructing my deconstruction.  Soon I’ll work up to mixing antipasto with penne, and then all hell will break loose.)

The Office of the Inspector General’s report on the VA laptop theft is a doozy.  It contains a lot of valuable lessons for those who can see beyond what most people are focusing on:  the lack of disk encryption. 

The employee explained that much of the data that he had stored on the stolen external hard drive was for his “fascination project” that he self-initiated and worked on at home during his own time. Because of past criticism on the reliability of the National Survey of Veterans, his project focused on identifying approximately 7,000 veterans who participated in the 2001 survey, in order to compare the accuracy of their responses with information VA already had on file. He began the project in 2003, but could not recall spending time working on it during 2006.

First off, the employee took this data home to work on his own project, about which his management knew nothing.  This points to a serious lack of communication and supervision on their parts.  But notice also that he was schlepping this data around for THREE YEARS.  Did no one take a look at his laptop or external hard drive in all that time?  Did they even have a refresh cycle, and if so, what was it?

To conduct this project, the employee took home vast amounts of VA data and loaded it on an external hard drive. The stolen laptop did not contain VA data.

I have no idea at all why this is supposed to be even worth differentiating.  See below.

While the employee stored the laptop and the external hard drive in separate areas of the house, he acknowledged that he took security of the data for granted.

Now, this is amusing.  Just where did he store the two so that he felt that this improved security?  Did he store one of them under a mattress? 

This is something that executives STILL don’t get:  whenever you allow mobile devices or remote access, you are relying upon the security of wherever those endpoints happen to be. You’re relying on the physical security of hundreds of employees’ homes, the security at Starbucks, the security at the Paris Hilton (sorry, couldn’t resist; it’ll up my Weird Google Hit Quotient), the security at the airport kiosks, and anywhere else your users happen to be—all at once.  In other words, you’re relying on the security of the USER, not the device they’re using.  Your perimeter is no longer a shield wall; it’s a blob of Jell-O.

As I’ve said before, our information has turned to water, and it’s flowing everywhere.  Another problem is that a lot of web-based applications act like sprinklers. 

Let’s look now at the chain of reporting events ...

Mr. Michael McLendon, Deputy Assistant Secretary for Policy, was one of the managers notified on May 3, 2006. However, it was not until May 5, 2006, that the Information Security Officer (ISO) for OPP&P interviewed the employee to determine more facts about the loss. The ISO reported that the employee was so flustered that the ISO decided not to discuss the matter; rather he asked the employee to write down what data was lost. The employee’s written account of the lost data was an identification of database extracts with little quantified information concerning the significance or magnitude of the incident.

So where was the ISO on May 3rd?  And for pity’s sake, why didn’t he work harder with the employee to get the facts of the matter right then and there?  He could have given him a Xanax, or something.

Mr. McLendon received the report of the stolen data on May 5, 2006. Instead of providing the report to higher management, Mr. McLendon advised his supervisor, Mr. Dennis Duffy, Acting Assistant Secretary for Policy, Planning, and Preparedness, of his intent to rewrite the report because it was inadequate and did not appropriately address the event. He submitted his revised report to Mr. Duffy on May 8, 2006.

Our review of Mr. McLendon’s revisions determined that his changes were an attempt to mitigate the risk of misuse of the stolen data. He focused on adding information that most of the critical data was stored in files protected by a statistical software program, making it difficult to access.

So he decided to spin the incident.  Not only that, but it took him THREE DAYS to rewrite someone else’s report in order to do it.

Mr. McLendon made these revisions without consulting with the programming expert on his staff or with the employee who reported the stolen data. Mr. Duffy provided the revised report to Mr. Thomas Bowman, VA Chief of Staff, on May 10, 2006. Mr. Duffy also did not attempt to determine the magnitude of the stolen data nor did he talk to the employee.

So it took Mr. Duffy TWO DAYS to read this incident report after it was spun.  And nobody’s talking to the employee.  Don’t you think he would have calmed down enough to be interviewed a WEEK AFTER THE BURGLARY?

Mr. Duffy did not discuss the matter initially with Mr. McLendon, noting that there had been a long and very strained relationship with him.

Another Layer 8 issue comes to the fore.

Shortly after Mr. Bowman received the report from Mr. Duffy on May 10, 2006, he provided it to Mr. Jack Thompson, Deputy General Counsel, and asked him to provide legal advice on the agency’s duties and responsibilities to notify individuals whose identifying information was compromised. On May 10, 2006, Mr. Bowman also informed Mr. Gordon Mansfield, Deputy Secretary. While the Deputy Secretary does not recall discussing the magnitude of the number of veterans affected by the theft, he too decided not to raise the issue to the Secretary until they knew more information on what VA’s legal responsibilities were and more about the magnitude of the problem.

Here’s another thing they don’t teach you in most incident response classes:  the phase where everything gets bogged down waiting for Legal to weigh in.

The OIG was able to determine the extent of the stolen data after one interview with the employee on May 15, 2006.

Reading between the lines here, I’d guess that the Deputy Secretary sat on this another five days, waiting for Legal, before someone (probably Legal) brought it to the attention of the OIG.  The employee was most certainly lucid twelve days after the incident.

Twelve days after receiving the original incident report, the SOC [Security Operations Center] had made no meaningful progress in assessing the magnitude of the event and, ironically, had passed responsibility to gather information on the incident back to the OPP&P ISO to review it as a possible privacy violation, an area outside the jurisdiction of the SOC. The OPP&P ISO also serves as the Privacy Officer (PO).

So the SOC passed the ball (are they even ALLOWED to do that?) back to the person who messed up the investigation to begin with.  Nice work.  This is another growing trend that disturbs me:  treating security issues and privacy issues as separate ones, so that the latter can be seen with less urgency.  Privacy issues can be deliberated at a snail’s pace in the comfort of a boardroom.  Security issues are supposed to move faster.  The other problem with separating security from privacy is that you sometimes end up treating them as being mutually exclusive.

We found that policies implementing information laws focus on identifying what information is to be protected and the conditions for disclosure; whereas, policies implementing information security laws focus on protecting VA automated systems from unauthorized intrusions and viruses.

They didn’t have a policy that said “don’t take confidential data home.“  Fair enough.  But they also had a disconnect between understanding what data they could release and what data they had to protect.  They were doing security by media headline:  they were focusing only on external threats and mostly just on viruses.  Security was ignoring layer 8 because they assumed that was a “privacy” (i.e. legal) issue, not their bailiwick.

Let’s recap, shall we?  Here are some important points to remember about incident response:

1.  Know where your data is, and what people are doing with it.  It’s really, really hard, but try.  Whenever a computer is stolen (and I’ve seen whole servers carried off), the first question you have to answer is “What was on it?“—and it’s a lot harder to answer than you think. 2.  Don’t let personal issues get in the way of responding properly to an incident. 3.  Report up the chain early and often.  I’ve done tabletop incident response exercises where at every step of the way, when asked whether they had notified their supervisor yet, the responders would say, “No, not yet, I need to find out more information first.“  And this would be with the supervisor in the room, at the same tabletop, saying over and over again that he wanted to be notified immediately, no matter what!  Notify early and often. 4.  Incident status reports should always include who has the ball, and why. 5.  Don’t wait for legal opinions to continue with the rest of the security response.  Better yet, have your general counsel hooked into the security process early, and make sure to have him/her on call and on speed-dial. 6.  Yeah, okay, get the disk encryption too.  But make sure it’s really being used, and don’t make it your only line of defense. 

I sure hope they tossed out the VA ISOs with more alacrity than they showed in dealing with this incident.  If there’s no enforcement, and no accountability, then no amount of great policies is going to prevent this sort of thing. 

Posted by shrdlu on Sunday, August 20, 2006
(3) Comments • Permalink •