UBS Trial Aftermath: Top 10 Tips For A Successful Postmortem

The government's forensics investigator says UBS took an important step when it examined the 2002 attack on its system. Here are some tips on creating your own successful postmortem report.

Once the dust had settled after the March 2002 attack on UBS PaineWebber's network, company managers began taking stock of what happened, and from there, figured out what they could learn from it.

Lessons learned came in the form of a postmortem report that touched on security weaknesses that could be tightened up and processes that could be put into place to fend off another attack. Keith Jones, the government's forensics expert, and director of computer forensics and incident response at Mandiant, an information security company, based in Alexandria, Va., says he was impressed that UBS tackled this kind of evaluation after such a traumatic incident.


More Insights

Webcasts

More >>

White Papers

More >>

Reports

More >>

But that's exactly the time when an evaluation will do the most good, he points out.

The defense attorneys for Roger Duronio, who was found guilty on Wednesday of launching the attack against UBS, tried to use the postmortem report against the company. Duronio's team pointed to security weaknesses brought up in the report as evidence of a flawed security architecture that could have allowed anyone to perpetrate the crime.

And while any kind of report ultimately could be used against a company in a similar situation, the benefits of doing a postmortem greatly outweigh any drawbacks, says Jones. Here is his Top 10 checklist for conducting a successful postmortem study:

1. Start Now: Ask employees who are working on remediation to keep notes about what issues they're dealing with as they go through the process. And then start the official postmortem study as soon as the system is back up and running.

2. Who To Include: When working on the study, cast a wide net. Make sure you talk to business managers and IT people who were there the day of the attack, the IT people who worked on bringing the system back up, the human resources people and the company's legal team.

3. Allow For Anonymity: Accept anonymous input, but be sure to keep track of what department the person works in so the input can be weighed appropriately.

4. Avoid Blame: Don't start a witch hunt. It's human nature to look to blame someone, but be aware of that danger and keep questions, and the ultimate write-up, as objective as possible. Concentrate on ways to improve.

5. Look For Answers: Encourage people to submit solutions along with each problem.

6. Create A Checklist: Go through all the interviews and the resulting study and identify the problems and the proposed solutions. Make a checklist of what needs to be done.

7. Focus In: While lots of people may have ideas for different solutions, take the time to go through them, and select the best one to go with. Don't finalize the report with potential fixes. Solidify a plan.

8. The Sooner The Better: Once you have identified problems and solutions, get cracking. If it's a matter of a missing patch, get it fixed immediately. If it's a matter of a missing policy, that will take more time to implement, but get the process started.

9. Legal Document: Remember that the postmortem is like any business document, and could end up being examined by company outsiders during any legal action.

10. Track The Progress: Make sure someone is keeping track of the progress being made to resolve each and every problem found.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS

Resource Links