Welcome to Day 28 of the SANS ISC's participation in the Cyber Security Awareness Month. Today's topic is how to avoid finger pointing and the blame game. During the recovery phase of the incident, some discussion about responsibility of the incident and fault start popping up, these discussions can become distractions to the recovery process and ruin morale.

Please write in if you have any ideas or tricks to

- Promote focus on handling the incident rather than the blame
- Avoid finger pointing to begin
- Stop the blame game in its track

Please let us know by using the contact form. We will update this diary throughout the day. Thanks!

 Keith Rosenberg wrote in with the following comment,

If IT promotes and maintains good relations with the users, they will be very willing to call the help desk when their machine is first infected with something and not after a week or more. Not blaming the user for the malware, they probably feel bad enough already, is one way to do this. While fixing their computer, at a moment when they are usually most interested, (re)educate them by going over the ways the user can help prevent malware infections.

Jax wrote in with the following comment,

A good technique for avoiding the blame game all together is not to refer to anything in a personal manner.
When refering to the IDS/IPS do not say the IDS section, say 'the sensors'.  Never refer to 'bob' at the firewall section, soley refer to 'the firewall'.
Avoid personalisation, avoid assigning gender and names, and thank everyone for their good work and continued support.  After all we are here for the incident resolution and recovery not to assign pitfalls.
Also never say lessons identified and lessons learned, because that automatically gets units on the back foot and defensive, because people learn and identify.
De-personalisation is the key, people work, help and resolve; they do their best with what they have got.  Which can be old, unsupported and on its last legs mearly held together by hope and duck tape.
We are the only people that can makes things better.  For inspiration I find the following quote from X-Files Season 4 Episode 19 (I think) works.
' There are extraordinary men and women and extraordinary moments when history leaps forward on the backs of these individuals, that what can be imagined can be achieved, that you must dare to dream, but that there's no substitute for hard work and teamwork because no one gets there alone; and that, while we commemorate the greatness of these events and the individuals who achieve them, we cannot forget the sacrafice of those who make these achievements and leaps possible'
That person, that team is you and your security/administration team.  We are one, there is no single point of failure, we all do our best and help each other for the good of the networks.

Paul Davis wrote in with the following comment,

Finger pointing and the "blame game" usually make an apperance when people feel threatened or the atmosphere of cooperation and team work has been removed.  There are a couple of pointers:
1) Be proactive before the situation occurs.  Make sure that everyone understands their role and responsilibities.  Build a matrix and identify the principle owner, the support groups and the influencers.  Include the matrix not just the technical aspects, but also the business owners, the data owners.  Walk everyone through the matrix so that they do understand what is expected from them and what they can expect from others.  Makes things much easier.
2) During the incident.  There will be times when stress levels rise and people emotions get in the way.  In those situations, you need to have an experienced leader who can recognize the signs, defuse tense situations and understand how to drive to a solution.  They dont have to be pure  security gurus but they do have to have business, technical, people skills and a level of security understanding.  Some of the tricks I have used is to seperate the groups, take 5 min breaks, change the paradaigm to get them to think about the problem different.  But you also have to be tough, if someone makes a commitment to the team, make sure they understand what they are committing, that they accept the deadlines and also articulate their risks and concerns.  And hold them to that commitment.
3) Be available.  As an incident leader, people have to be able to contact you all the time. If someone has a concern but they dont want to voice it, make sure that they have a back channel of communication to you.  They make be embrassed, unsure and just paranoid, but sometimes those concerns can be "incident breakers".
4) Keep your priorities in focus.  If your number 1 priority is to protect a business or people, then make sure the group keeps the same focus.  Don't let technical curiosity get in the way of recovering a business or to protect one or more people.

There are many more but the primary success factor for me has been being prepared.  Investing time and effort, so that you can handle the unexpected.

Francois wrote in with the following comment,

Working with end users, in training I've always beat the drum on two issues.

First, if there's any doubt about a situation, whether a virus or any security issue, I tell users to always call support. I tell them, make it an IT issue, not your issue. IT will take responsibility for it. My philosophy is that any security that depends on the end-user is a recipe for failure. People make mistakes and end users cannot be expected to manage security concerns. If a user does get a virus, the controls - and responsibility - fall squarely on the security team.

Second, I always tell end users they will never, ever be penalized for reporting a security concern. No matter whose fault it is, no matter if it's valid or not. In fact there should be some sort of reward for users that are proactive. E.g., in the next meeting or training, "Thank you to Joe for contacting us instead of opening that suspicious e-mail, good job."

If the user violated company policy by committing the breach - that, perhaps, deserves a penalty, and should be handled with discretion. But reporting the issue should never be penalized.

Dave wrote in with the following comment,

As IT manager in our organization, I explain that our team function is to identify a problem, find it's cause, and then determine a resolution.  I explain that we should not care who may be at fault, or who may be to blame - that is for upper management to decide and act on.  It is our responsibility to determine and then remedy so that it does not occur again in the future.

Any other energy spent on things outside our goal strategy is both wasteful and counterproductive and means the team will have to work longer and later to accomplish our real task.  This would cause a delay in accomplishing our task, and this delay could also be perceived by upper management as a lack of performance and efficiency on our part, thus hurting the reputation of our team and putting us at fault.

I have only had to put it this way to the team once, and it has never come up again.

Leonard wrote in with the following comment,

Lay your cards on the table:

This is what I see or my devices show this.  The ask if they see any errors or omissions in what you have and ask them what they see on their devices.  Be prepared to troubleshoot with them and monitor your devices to interactively work on the issue.

Over time some it will get easier as people know you will work with them to solve the issue.

David Longenecker wrote in with the following comment,

It seems simplistic, but one of the strongest ways we as incident handlers can minimize finger pointing is by steering discussions toward mitigating the problem at hand.  Speaking from a leadership role, our teams will follow our example, and frankly many incidents are simply so chaotic that if we move on to mitigation, the blame game just gets forgotten and left behind.

The second half of the equation though is knowing there will be time to root cause the situation later.  In my organization, we have a well-established process of handling the event, then dealing with the root cause in a post-mortem fashion.  Stakeholders know they will have an opportunity to go after the original cause after the incident is resolved, and thus are quite willing to forego the blame game.

As a side note, human errors are dealt with sensitively, among only those that need to know.  Our culture is that it serves no purpose to publicly humiliate someone, even for gross negligence (although in a case of gross negligence, the person may not be working for us next week.)