Slashdot Mirror
Survey: Most IT Staff Don't Communicate Security Risks
CowboyRobot writes "A Tripwire survey of 1,320 IT personnel from the U.S. and U.K. showed that most staff 'don't communicate security risk with senior executives or only communicate when a serious security risk is revealed.' The reason is that staff have resigned themselves to staying mum due to an environment in which 'collaboration between security risk management and business is poor, nonexistent or adversarial,' or at best, just isn't effective at getting risk concerns up to senior management."
IT would love to, but upper management doesn't want to hear it.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
"However, it's clear from this report that most organizations are missing the majority of opportunities to integrate security risks into day-to-day business decisions. Changing this paradigm will require security professionals to develop new communication skills so they can talk about security risks in terms that are clearly relevant to the top-level business goals."
Is it possible to cram any more buzzwords into that paragraph?
I send out security risk info to our employees every so often, but not all the time.
Send them out too often, and you risk being ignored. Send them out infrequently, and people say they weren't warned. Once a month seems to do the trick where I work. Management actually encourages this since it keeps people aware without becoming annoying.
Yes, I did stop communicating security risks eventually. I'd say I stopped after the 10 or 20 thousandth 'So what?' from management.
Security = Liability. There is no other way to look at this from the bean-counter point of view. This is why all organizations need CIO, someone who is capable of translating "if we don't do X, we going to get pwned" into "if we don't spend X$ and Y man-hours, we are exposing our business to $Z,000,000 -sized liability".
This problem boils down to techies and suits not speaking the same language. So someone has to translate.
DAMMIT wrong thread!
This was supposed to go in the helicopter RV kills guy thread.
nothing to see here, move along folks.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
here.
Have gnu, will travel.
As someone who has been working in IT for almost two decades, I'm not the least bit surprised. There are all kinds of things that we've given up on trying to communicate. People don't want to hear it. They don't understand what you're saying, they don't want to figure it out, and if you can get them to understand, they still don't care.
In the case of security, it falls into this classification of 'technical things nobody even wants to understand' and also into the classification of 'preventative measures that people will not recognize the importance of, until after it bites them in the ass.' You tell people that it's a bad idea to use "password" as your password, and they'll blow you off. The more you stress the point, the more annoyed the'll become-- all the way up until someone malicious gains access to their accounts. Once they've been hacked, they'll come back angry, demanding, "Why didn't anyone tell me it was a bad idea."
Until there's an actual security breach, people think you're chicken little. They'll tell you, "I've been using 'password' for my password for 10 years and I've never had a problem."
Face that kind of attitude for a several years, and you get awfully tired of warning people.
6x% said there was a communication problem. 61%, or almost all with a problem, said it was too technical for management to understand.
One commenter talked about trying to explain escalation attacks and ssl issues to the boss. Yeah, my boss wouldn't understand that either. He does understand BUSINESS RISKS. If I point to a WSJ or Forbes article about a company that got owned and say "we are vulnerable to the same thing" he'll understand that. He doesn't understand SSL ciphers, he's not supposed to. He does understand "PR nightmare" and "noncompliance".
If I want business managers to do something, should I maybe explain the business case for what I'm proposing? Maybe point to a line in the WSJ article that says "the attack is estimated to have cost the company $2.4 million so far. No word yet on when their services will be back online". Perhaps that's what management understands better than the technical details?
To take that a step further, it would be interesting to see what happened if those complaining of poor communication emailed their boss saying:
You may have seen the Forbes and WSJ articles related to the security breach at XYX Corp.
We are currently at risk for the same type of issue. I estimate a 6% chance of a breach in the next three years which would cost the company around $1 million,
so we have an actuarial liability of $60,000. If we secure the system, I estimate the risk would be reduced to 3%, eliminating $30,000 of the liability. I estimate the cost as $4,000 to eliminate that $30,000 liability and much of the $1M risk.
That you you are presenting management with this decision "do we want to save $30,000 by spending $4,000?" That's not too technical, that's exactly
the decisions they are trained to make.
Looking at it that way can also teach we engineers something. We might estimate the cost of a breach at $30,000 with a 1% chance of it happening. That's a $300 liability. If it would require 10 man-hours to fix, including meetings and stuff, the company would lose a lot of money trying to fix it. (Remember people cost approximately double their salary, once you pay for health insurance, taxes, their office space, etc.) Management would be "right" to simply accept the risk, knowing that bad might happen, at a cost of $30K. Better to risk a $30,000 problem that probably won't happen than to spend $2,000 avoid it. (Best would be to make a note to fix it in the next version / rewrite, when the _extra_ cost is only 1 man-hour.)
I've been in IT-Security for about a decade now. I've had my share of consulting jobs and inevitably a poor security communication comes down to one of three reasons:
1. Ignorance at management levels
2. Blame-shifting
3. Blinkered management
Let's shed some light on them.
One is easily explained and I guess everyone can tell at least one tale of them noticing something being horribly wrong in their IT setup, dashing to their superior, reporting the finding and being met with a blank stare and a "huh? Erh... ooookay... we ... I mean, I will look into it...", leaving you with the feeling that entrusting your superior with a problem is like dumping a baby into a trash can. When this happens more than once, IT becomes complacent as well. Management doesn't give a fuck, so why should we?
The second is actually worse, but rather common around Europe in my experience: The person who reports the finding gets the blame. Directly or indirectly. Either they get chewed out why they could let that happen (whether it is actually in their responsibility or not), or they are now seen as some sort of management snitch with his peers 'cause he ratted them out and now someone gets the blame. This is usually the case in companies where finding a culprit has a bigger priority than finding the person who can fix the problem. It's amazing how often that is actually the case.
And finally, management that just doesn't give a fuck. It is usually somehow tied with the first case, ignorance of the importance and size of a problem is tightly coupled with the willingness to ignore it altogether and wish it away.
In a culture like that, NOBODY is very keen to report problems. It's time management starts to understand that problems are part of the game and nothing that can easily be avoided. The human factor is always in play when work is done, and humans err. By definition. Anyone claiming he doesn't make mistakes simply does not work. It is that simple. Only if you don't work you cannot make mistakes. So mistakes will happen and problems will arise. It is now very pointless to start pointing fingers and spending resources finding the culprit, because after we found him we still have the problem on the table! We can do that AFTER the problem is solved. That not only gives the person responsible for it the chance to fix it themselves, but it is also the sensible order of doing things. First get the problem fixed, then you find a strategy to avoid repeating the mistake. Yes, that may include replacing the person responsible for it, but first of all we should find out just WHY he made that mistake, WHY it was possible for him to make it (actually, 9 out of 10 times it's NOT the person's mistake, it's a mistake in the process. But it's just easier to fire some easily replaceable worker than the process manager...) and HOW we can avoid making it again. Just replacing someone does NOT fix a problem if the process behind it is shot, because the next person will make the SAME mistake again.
But I ramble, back onto security reporting.
Companies need to establish a culture of security awareness amongst their workers. Security is the minimum of technical and staff security. The MINIMUM. Not the average. I can have the tightest security system in the world if the users hand out their passwords to anyone calling. Of course, preferably the human factor would be taken out of security altogether, but that is not easily possible. Security reporting must be a process, and a process that is rewarding for the person reporting. Someone reporting a security risk must not be seen as a "problem maker", as he often is. He upset the apple cart, he put sand into the gear, he makes the machine run wobbly. Everything went smooth and then that idiot comes along and says we're insecure. So what, anyone see anything bad happening? This is, sadly often, the approach taken to ITSEC. We have to understand that someone who reports a security problem is not "making" this problem but actually helping us avoid a much bigger problem.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If you are asking for resources to be spent to avoid a particular risk, you either have the professional knowledge to discuss the level of risk, or you're talking out your ass.
How can you get that knowledge? We logged just over 10,000 brute-force attacks last year on the x,000 sites we monitor. I can query those logs to provide various numbers. So logging is one way. The major security lists get several reports per day. MMonitoring those lists will help you understand the threats - how common they are, how costly they are, and how to mitigate the risk. Sometimes engineers focus on mitigation, but knowing how to mitigate risk is pointless until you know which risks you should be focused on.
Suppose you don't have time to learn about all that. You probably don't have time to learn about a lot of things, so you listen to some experts. Bruce Scheiner or myself might post something you'll want to read and feel you can trust. If we security professionals do our jobs right, we'll include some risk assessment data. You can always ask us questions. Every three years, you might call one of us in to look at your systems and provide some specific recommendations, along with information about WHY we recommend those things.