Blatant Disclaimer
Edit: Part 2 of this series is posted here.
Before I start, let me say that I had to carefully consider how to word this post. I talked to some peers who advised that I not write this at all. After all, who among us can say that we did everything perfect in every incident response we've worked? I certainly can't. I'm not going to Monday morning quarterback the work of my industry peers and you shouldn't either. But after careful consideration, I decided that there are lessons learned in examining the legal filing. I'll break this into several posts over the next week since there's a lot to cover.
Case background
The case background starts something like this: Affinity Gaming was notified that their payment systems were likely breached. Like most, the breach was detected through external means. Affinity contacted their insurer who told them to find a PCI forensics firm and supplied them a short list from which they selected Trustwave.
Trustwave investigated, completed their investigation, and issued the results of the forensics investigation. They also made several unspecified recommendations to Affinity for securing their systems and preventing future attacks. Months later, Affinity discovered that attackers were still in the network. Affinity hired Mandiant who discovered that the original attack had never been remediated and that several systems investigated by Trustwave were infected with malware (which they failed to detect). Mandiant also advised Affinity that the unspecified recommendations from Trustwave would not help secure their network.
Today's analysis
Today, I'm going to focus on scoping. The first thing that hit me in the legal complaint is that the plaintiff, Affinity Gaming, asserts that they are not infosec experts. In fact, Affinity asserts this is why they hired Trustwave to perform an incident response. This is an excerpt from the filing supporting the claim of "Constructive/Equitable Fraud."
Many times, I notice that consultants are afraid to tell clients the hard truth. At Rendition Infosec, I've worked several incidents where clients have a strong desire to say that they have remediated the incident completely when they haven't scanned all machines on the network for the indicators of compromise (or have done so ineffectively). In some more extreme cases, clients have said that all machines on the network are clean without even having a device inventory or understanding how many machines they even have. After all, even Confucius* says "you can't investigate compromises on machines you don't know you have."
* Actually, I made that up. I don't think Confucius ever weighed in on incident response.
Give it to them straight
Over the years, I've lost some business by telling it to clients straight: "I know you wish the incident was over - but you are nowhere near done investigating. You can tell the board whatever you want, but you won't get a clean bill of health from me until we've completed a thorough investigation in accordance with industry norms." Many consultants and employees on internal teams are afraid to do this and upset management.
When discussing this with an industry peer that I know and trust, she said "there's no right answer here. Either way you risk losing the client." I respectfully disagree. If you tell the client the hard truth that the scope is larger than they desire you do indeed risk losing the client. But this filing shows that if you don't tell the client the proper scope (and stick to it) you not only risk losing a client, but also being sued.
So what was the scope?
The short answer is that we don't currently know. However, this excerpt from the filing provides some clues about the initial scope:
Edit: Part 2 of this series is posted here.
Before I start, let me say that I had to carefully consider how to word this post. I talked to some peers who advised that I not write this at all. After all, who among us can say that we did everything perfect in every incident response we've worked? I certainly can't. I'm not going to Monday morning quarterback the work of my industry peers and you shouldn't either. But after careful consideration, I decided that there are lessons learned in examining the legal filing. I'll break this into several posts over the next week since there's a lot to cover.
The case background starts something like this: Affinity Gaming was notified that their payment systems were likely breached. Like most, the breach was detected through external means. Affinity contacted their insurer who told them to find a PCI forensics firm and supplied them a short list from which they selected Trustwave.
Trustwave investigated, completed their investigation, and issued the results of the forensics investigation. They also made several unspecified recommendations to Affinity for securing their systems and preventing future attacks. Months later, Affinity discovered that attackers were still in the network. Affinity hired Mandiant who discovered that the original attack had never been remediated and that several systems investigated by Trustwave were infected with malware (which they failed to detect). Mandiant also advised Affinity that the unspecified recommendations from Trustwave would not help secure their network.
Today's analysis
Today, I'm going to focus on scoping. The first thing that hit me in the legal complaint is that the plaintiff, Affinity Gaming, asserts that they are not infosec experts. In fact, Affinity asserts this is why they hired Trustwave to perform an incident response. This is an excerpt from the filing supporting the claim of "Constructive/Equitable Fraud."
Trustwave knew that Affinity Gaming needed to rely and did rely on Trustwave’s claimed specialized knowledge, experience and qualifications, and on information supplied by Trustwave, in making decisions on engaging Trustwave to investigate, diagnose and remedy or contain Affinity Gaming’s data breach, and in believing that Trustwave had in fact diagnosed and remedied or contained such breach, because Affinity was not able to detect the falsity and incompleteness of the information supplied by Trustwave;Elsewhere in the filing, Affinity notes:
Affinity Gaming trusted, and was dependent on, Trustwave’s assessment on what the proper scope of its engagement should be, given Trustwave’s data security expertise, and in no way limited or restricted Trustwave’s investigation of Affinity Gaming’s data systems.I have no inside information here so we won't really know what happened until facts are presented at trial. What's I will note is that scoping any engagement is important. During an incident, the client always wants to get back to normal operations in the shortest period of time for the lowest overall cost. This lawsuit provides an example of the need to clearly communicate the scope required to resolve the incident. Trustwave may have done this, but Affinity asserts they did not.
Many times, I notice that consultants are afraid to tell clients the hard truth. At Rendition Infosec, I've worked several incidents where clients have a strong desire to say that they have remediated the incident completely when they haven't scanned all machines on the network for the indicators of compromise (or have done so ineffectively). In some more extreme cases, clients have said that all machines on the network are clean without even having a device inventory or understanding how many machines they even have. After all, even Confucius* says "you can't investigate compromises on machines you don't know you have."
Give it to them straight
Over the years, I've lost some business by telling it to clients straight: "I know you wish the incident was over - but you are nowhere near done investigating. You can tell the board whatever you want, but you won't get a clean bill of health from me until we've completed a thorough investigation in accordance with industry norms." Many consultants and employees on internal teams are afraid to do this and upset management.
When discussing this with an industry peer that I know and trust, she said "there's no right answer here. Either way you risk losing the client." I respectfully disagree. If you tell the client the hard truth that the scope is larger than they desire you do indeed risk losing the client. But this filing shows that if you don't tell the client the proper scope (and stick to it) you not only risk losing a client, but also being sued.
So what was the scope?
The short answer is that we don't currently know. However, this excerpt from the filing provides some clues about the initial scope:
In its PFI Report, Trustwave defined the “initial scope of the engagement” as inspection of only 10 servers and systems and Affinity Gaming’s “physical security” and “network topology.”Depending on the background (which we are not privy to yet), this scope seems adequate. However, once Trustwave determined that servers were infected with malware, they should have at a minimum determined if the same malware (or malware variants) were installed elsewhere in the network. This is apparently where things broke down, because according to Affinity the scope was never changed to reflect the changing environment with the initial discoveries.
Despite indications that Trustwave should have expanded its scope of engagement – such as Trustwave’s suspicion of a backdoor component, and identification of an open communication link that led outside of Affinity Gaming’s systems – Trustwave did not do so, nor did Trustwave recommend any such expansion to Affinity Gaming.
If this goes to trial, we'll learn what recommendations were made by Trustwave and when they were made. Whether you are a consultant or work on an internal team, you can learn from this. When new knowledge is gained, the situation changes. When the situation changes, you need to re-evaluate the scope of the IR. And based on this lawsuit, I'd certainly advise making sure that there is a written record of those discussions about re-scoping the incident. You never know who will be next.
Using Kaspersky protection for a couple of years now, I'd recommend this Anti-virus to all you.
ReplyDelete