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."

Comments

one-way street

[X0563511]

IT would love to, but upper management doesn't want to hear it.

Re:one-way street

[intermodal]

Or, more to the point, they don't understand it even if you try to tell them. And many in upper management, if you communicate the problem, will immediately turn it on you, wanting to know why you haven't fixed it already.

Re:one-way street

[robinsonne]

Exactly.
Management doesn't want to hear about it.
Management doesn't understand it.
Management doesn't want to spend money on it.

Nothing happens until it becomes an "issue" and then it's somebody in IT who gets the axe while everyone above is covering their asses.

Re:one-way street

[Shoten]

IT would love to, but upper management doesn't want to hear it.

Partially true, but not universally so. The problem is more that technical staff speaks in terms of technical risks, while upper management thinks in terms of business risk, and the two are not obviously aligned. It's like a patient who wants to know "how bad it is," and the doctor answers in terms of probability of due to . The key is to be more proactive about it, and to qualify where a business/organization is strong or weak in terms of security, while providing a plan to improve things down the road. It's impossible to tell someone what the odds are of X being compromised due to Y risk, resulting in Z cost; the best you can do is look for weaknesses and then come up with a plan to prioritize and fix them. Upper management understands the need to be secure, but they need to be given something they can understand and act on or approve. They won't make decisions based on things they don't understand (if they're smart).

Of course, if compliance comes into the picture, then the risk definition changes. It no longer becomes about risk of compromise, but risk of fines due to noncompliance. This makes it very easy to categorize the risk and communicate it...and as a result, compliance-based security spending is very high compared to security-based security spending.

Re:one-way street

[ohieaux]

And that is the crux of the matter. Risk must be quantified in the units that business decisions are made - dollars. Beyond that, risk needs to accurately assessed to the point of what is the likelihood and not what is possible. Once we know the likelihood and the cost, decision makers will be able to make their decisions.

Re:one-way street

[Moryath]

This, this, a thousand times this. Upper management are always deliberately clueless about security, unless the company is in the business of security.

Actually having security means:

- Management has to bother complying with it.

- Management has to NOT constantly carve out exceptions to it ("I'm the CEO, I'm too important to have to remember my own goddamn password or take 5 seconds entering it into a computer in the morning! Now where's my intern to deliver my coffee and morning blowjob!")

- Management has to spend the money on the maintenance and monitoring of it.

- Management, who have the purchasing / decisionmaking power, have to step away from getting blowjobs from pretty interns long enough to actually look at the competing products/options and make a decision.

- Upper Management will always privilege Middle Management over those whose job it is to deal with security. See point 2 about exceptions: middle management complains "security makes it impossible to get our work done" and the response from Upper Management is never to have the staff spend some time training and understanding the security and why it's there and how to work WITH it, it's "fuck you security why are you getting in the way of business? Shit, I'm taking time off from my two-blowjob lunch to deal with this!"

And just TRY to talk to them about two-factor identification (via cellphones or a swipe-card or something). You will get nowhere because the brainless, Peter Principle, Fail-Upwards recipients of CEO/CTO/CFO jobs will say it's "too much work" for them to comply with.

Re: one-way street

[nospam007]

"IT would love to, but upper management doesn't want to hear it."

Exactly! Nobody wants to hear it. The security people also don't report that the locks are crappy, the fingerprint reader laughable and the cameras are so lame that a mother wouldn't recognize her kids.

If it works, don't bother us, especially not if it costs money to fix.

Re:one-way street

[Moryath]

"Why haven't you fixed it yet?"

- Because we're coming to you right now to get authorization to spend the money required to fix it.

"Rarglkebargle that's too expensive, find a free solution instead. Now where's the intern for my morning blowjob?"

- There is no free solution. It takes time, hours, and a certain amount of training for the staff to get them to understand and help them comply with the security policies.

"Rargle I'll just find someone else then. Fuck you, you're fired. Time for my powerlunch with the other cocaine-addled executives! Hey, I just saved the company your salary! I think I'll award myself some stock options for my brilliance and frugality!"

Re:one-way street

[JustOK]

The risk of this vulnerability is 2.5 Snowdens.

Re:one-way street

[GargamelSpaceman]

Mark Twain said something along the lines of 'It's easier to fool people than convince them they've been fooled.'

Re:one-way street

[Moryath]

They're CEOs which means they are Fox-addled GOP types. Quantify it in Obamas and all of a sudden they'll spend everything in the world to get rid of it.

Re:one-way street

[GargamelSpaceman]

Management that hears it is put in the position of either using their budget to fix it to standard which they should have been following but weren't gaining them nothing, or admitting that THEY screwed up and asking for additional funds from their manager who would be in a similar position.

Re:one-way street

[Feyshtey]

Or worse, their ignorance spawns knee-jerk reactions that cripples wide swaths of the workforce's productivity.

"What!? There's IIS vulnerability on serverXYZ ?! Uninstall all IIS on all systems immediately!"

Re:one-way street

[Ice Tiger]

Get the person next up in the chain of command to sign off the risk, then they pass it up the chain of command and so on and eventually you get the money you want.

Works every time as no one wants the responsibility.

Re:one-way street

[Shadow99_1]

My personal experience has been I could stand on a chair and wave my arms as I shouted about it and if it either costs them money or inconveniences them in the slightest (even if that is just not being able to use 'god' as their password) then they refuse to listen. Then if their is a security issue they blame you for not 'fixing' it.

Re:one-way street

[Anonymous Coward]

For my own experience, having brought security concerns to 'responsible' adults during my formative years in school, I was trained that doing so instantly results in demonization of the messenger. NEVER EVER point out that the emperor has no clothes.

This is fairly common in schools, and other organizations. How much does this behaviour train people to silently ignore security issues when discovered for fear (often well earned fear) of unjust reprisals for bringing them to the attention of those who are 1) most affected 2) responsible to prevent/fix these issues?

Re:one-way street

[Anonymous Coward]

Someone's upset!

Re:one-way street

[Anonymous Coward]

Actually, it is more complicated then that.

Companies only have so much money, time and people. They have to choose what they do and what they don't do. There is no way to chase down *every* risk. So a decision has to be made as to which risks to address and which not to. There is also the question of how to address the risk.

In general IT is very poor about being able to quantify the risks and formulate plans (and costs) for addressing them. This makes it essentially impossible for management to decide which risks to address and which not to.

I can cite some examples:

At a certain well-known company, a manager was approached and told that a certain networking nexus was entirely inadequate and that a dedicate space had to be carved out to house the networking equipment plus HVAC, power backup, etc, etc, etc. After spending 2 weeks trying to figure out how to do such a thing and how to do it in a way that wasn't going to cost a small fortune, management went back to IT and said "here is what we can do to accommodate your requirement, here is how much it will cost, and here is what is involved and how long it will take". IT's response? "Um, oh, I didn't realize it was that hard. Actually, all we need to do is put a lock on the cabinet, actually..."

It is this sort of interaction, where IT people adopt purist, and often extreme, position based on "principle" and make wild requirements, when in reality nothing of the sort is actually required, that causes a breakdown between IT and other departments. It erodes their credibility when it is discovered that the "requirements" are actually not required at all, but merely represented some sort of ivory tower fantasy.

And before people attack this post - I am not a manager. I am an Engineer. I have made this comment to other engineers and IT staff in the past because I have seen many, many technical people become so myopic with respect to "technical perfection" that forget that there are other, often much more "mundane", issues to consider - not the least of which is that nothing is 100% and there is no way to do everything that one wants.

Re:one-way street

[gmuslera]

Worse than that, upper (and middle, and even lower) management orders you to do things that goes against security, like opening access to the intranet from the whole internet so they can access it from anywhere they are, asking full access for their portables, no matter what they have installed or where they use it, transfering remote access passwords by unencrypted mail, and of course, their phones. And any recommendation to do any of this a bit more secure get scrapped because they are "complicated".

Also, sometimes they can't get why something related to security is important, they have their own ideas, opinions, and biases. After several times explaining how something security related is important and essential and the other side don't want to hear, don't understand, don't think is necessary, or orders you to do instead something that don't solve the core problem, you just give up on that.

Re:one-way street

[Anonymous Coward]

Also, who gives a fuck anymore? When you get ignored when you ask if the password to the Wi-Fi really should be "PASSWORD" or if the administrator password to the Windows servers REALLY should be "Password" you stop just caring. .... BTW. The people who made these brilliant security decisioned have more than twice my salary. These are just the zombie shot in the heat level brain dead ones, there is tons of "normal" zombie level ones too.

Also we MUST have firewalls between each department! Other-vice we will not be secure. And we had better open all the ports so all the software runs OK! Should I kill myself or become unemployed? (also everybody has to change their password every month, its 10chars and must be upper+lower+digit+special or it will NOT be secure... of cause this does NOT apply to the admin passwords or the free for all $ shares. Who can see thIS C$ share anyway? Its hidden, right? (BTW. F*ck MS and the horse they rode in on) )

Re:one-way street

[Moryath]

Wouldn't you be too, if those in charge were also the problem?

Re:one-way street

[nine-times]

True. And even in the best case scenario, you've only managed to create more work for yourself on a hypothetical/speculative issue, when you're already overloaded with more immediate problems.

Re:one-way street

[NatasRevol]

That sounds like it would help productivity.

Re:one-way street

[Moryath]

Allow me to counterexample from real life to your aptly crafted strawman bullshit.

I worked part-time a few years back as IT (the lone guy) for a construction company. Not full time because they weren't willing to hire anyone for full-time, just "on call" hourly rates and a few hours of "maintenance work" each week. They kept the main company server, with all the technical drawings and blueprints and scanned contracts and everything else, on a rolly cart in an open closet area that had a back-access door with a broken lock. The server itself was 8 years old, constantly needed "cleaning for space" for all the documents they were dropping onto its poor, overworked, non-RAIDed, non-backed-up hard drive. This server kept both Active Directory and file storage on the same box. Recommendation to replace the server, preferably including a reasonable mirrored RAID in case of failure? "Oh it works fine just keep it going."

The lack of backup was because their CEO had bought a tape-drive system that maxed out at 60 GB and their documents had exceeded that years ago, and daily maintenance on it was done by "the secretary" until they downsized her and then by a guy who was the laziest and most computer-illiterate of their employees who didn't even show in the office half the time. Recommendation to replace it, with detailed info on why it was inadequate, was "It was perfectly good when I bought it just make it work."

All of their passwords were their username plus the number 1. When this was brought up as a security problem, the CEO's exact response was "I want to know all their passwords at all times in case I need to see their documents" (which he already had access to on the server anyways) and "plus I don't want to have to change my password and I don't see why any of them do either, nobody is going to bother guessing into our systems."

Right before I left, he bought Carbonite Home Edition and installed it on their server thinking it would be good enough because Rush Limbaugh had endorsed it. His password was his wife's name, all lowercase. Did I mention her name is 3 letters long?

I don't know what happened after that. They hired his nephew, who "went to college and knew all about that IT stuff" (warning sign: nephew had a burger-flippers degree from art college) to "train as a site supervisor and do the IT stuff on the side" and told me they didn't need an external guy any more. In many ways, I'm glad not to be bothered by them these days. I pity whoever had to clean up the nephew's mess.

Re:one-way street

[Anonymous Coward]

The typical response from management is: Do not tell me the problem, just tell me what you need and fix it. SEC compliance is a hurdle they do not want to deal with. Management's knowledge is only for speaker series at conferences.

Re:one-way street

[nabsltd]

See point 2 about exceptions: middle management complains "security makes it impossible to get our work done" and the response from Upper Management is never to have the staff spend some time training and understanding the security and why it's there and how to work WITH it

There are many organizations where it really isn't possible to "work with" security because security policy is implemented by a group of people who don't care what the business needs to get done to make money. There are also some organizations where "security" gives lip service to communicating and working with the users, but the reality is that the rules are created with CYA as the primary driving force. In other words, if something bad happens, the security group gets to say "obeying our rules would have prevented this incident".

In addition, I have never been in an organization where security policies were reviewed to determine if they were still applicable, nor have I been in one where the makers of the rules have asked anybody other than themselves about "what should we do about X?" End-users get no input, managers only get the broadest of input ("protect us!", "I don't care if we get hacked, let the users do their work!", etc.), and so you end up with a very small group of people who wield a lot of power in the organization. People generally like wielding power, and are loathe to give it up.

As an example, we're trying to get a data transfer application that uses a non-standard port to work through our firewall. The current test setup has no data that can even be remotely considered "sensitive" (e.g., test files are "lorem ipsum" or similar). But, before the port can be opened to see if the protocol will work at all, we needed to recompile some libraries to force the user of higher strength encryption. Now, our testing is hampered by the "too many changes" problem...is the config file for the app on both ends correct, does the encryption sync up, is the port open, is any IDS/traffic shaper/etc. causing a problem, etc. The correct way to test would have been to just open the port with a restriction on the outside IP address, and then we could just use the app with default config (no security, etc.), and make changes to get to a production config that met the security requirements. At that point, the firewall rule could be changed to allow the connections from arbitrary IP addresses we will eventually need.

But, because security has a veto on everything, we're spending a lot more time trying to figure out what is causing issues. A proper security group would understand when rules can be bent or broken (and even allow rules to be permanently changed), instead of blindly applying rules that they might not even have had a hand in creating (depending on turnover within the organization).

Re:one-way street

[Anonymous Coward]

Clearly we need to make IT a profit center!

Re:one-way street

[Anonymous Coward]

That's patently untrue. To quantify it in Obamas, we'd have to obfuscate the source code, have a union or two write the scripts to implement, complain that Widgets International is making too much profit with their systems not running the latest version of Hope and Change, and then try to get them to pay for it. Not to mention getting our panties in a twist because Widgets International made fun of us for putting on the "Mask of Security"

Re:one-way street

[Z00L00K]

It probably will, that's the scary thing.

Re:one-way street

[David_Hart]

As an example, we're trying to get a data transfer application that uses a non-standard port to work through our firewall. The current test setup has no data that can even be remotely considered "sensitive" (e.g., test files are "lorem ipsum" or similar). But, before the port can be opened to see if the protocol will work at all, we needed to recompile some libraries to force the user of higher strength encryption. Now, our testing is hampered by the "too many changes" problem...is the config file for the app on both ends correct, does the encryption sync up, is the port open, is any IDS/traffic shaper/etc. causing a problem, etc. The correct way to test would have been to just open the port with a restriction on the outside IP address, and then we could just use the app with default config (no security, etc.), and make changes to get to a production config that met the security requirements. At that point, the firewall rule could be changed to allow the connections from arbitrary IP addresses we will eventually need.

But, because security has a veto on everything, we're spending a lot more time trying to figure out what is causing issues. A proper security group would understand when rules can be bent or broken (and even allow rules to be permanently changed), instead of blindly applying rules that they might not even have had a hand in creating (depending on turnover within the organization).

It's the wrong way to go about configuring/testing the application... You should be testing the application in an isolated test environment and not on the production network. In fact, you could have gone to the firewall guys to install a test firewall in the test environment to iron all of these things out. The application should be fully developed, tested, and configured before you even think about connecting it to the Internet. It sounds like the implementation team wanted to take a shortcut and "just deploy it" without any consideration for security, etc... My opinion is that you're blaming the firewall guys because you didn't do you're homework...

Re:one-way street

[Feyshtey]

Not if you're a webfarm. Should you use something else? Yes. Should you yank the plug and then try to figure out how to bring your entire operation back online after the fact because a patch was missing? Probably not.

Re:one-way street

[Anonymous Coward]

Management: Here is your budget for the new year, also we need all new computers, like those tablet touch screen devices that I see everywhere. those are really neet we need them.
IT: Sir we just upgraded two years ago, we need to make sure that we have everything patched and tighten our security, the computers we have have all been tested and have a life expectancy of at least 3 more years.
Management: New computers get it done, I have a golf game I have to get to... (walks away)
IT: FRACK!

Re:one-way street

[leuk_he]

No, it is like truning your computers off to migitate the problems of as DOS-attack that is happening. Who needs hackers if you have management that does not understand problems.

Your "productivity" is just such a problem. There are always better products in the market, but big bang switches to them on a ad-hoc basis is the recipe to downtime.

Re:one-way street

[Shoten]

And that is the crux of the matter. Risk must be quantified in the units that business decisions are made - dollars. Beyond that, risk needs to accurately assessed to the point of what is the likelihood and not what is possible. Once we know the likelihood and the cost, decision makers will be able to make their decisions.

Ah, but here's the problem: It can't be done.

Explain to me how you will take risk and quantify it in dollars, when the attacks, the attackers and the vulnerabilities are changing over time. Explain to me how you will take the complexity of an environment with multiple critical paths...which will have changed by the time you're done mapping all of them, by the way...and map the vulnerabilities (all of them...you'll need to know this, obviously, and good luck with that) against those, in combination with a full on threat assessment of all the threat actors who may be interested in the organization as a target. Explain to me how you'll actually come up with a probability of compromise for every threat and vulnerability, and a cost for each possible kind of breach. Oh, and since capital planning will be determined using this, you need to predict, with a fair degree of accuracy, how all of this will change over the next 36 months (including guessing correctly about which capital budgets for other business functions will be approved).

This has been tried; it does not work. It costs an insane amount of money to do it, and this is why none of the security frameworks (CMMI, ITIL's security subset, COBIT, NIST SP800-53, etc.) try to do it. That's why you have to instead look at where you are weak overall, and work on improvement in general terms. There's no way to get to discrete numbers when it comes to this form of risk, because there are actual people on the other end of the equation, trying to change the numbers. It's not like most other forms of risk, where the outside cause is non-sentient and fairly quantifiable with actuarial means.

Re:one-way street

[Anonymous Coward]

It may not be like most other forms of risk, but it IS very like the form of risk involved in pricing securities and leveraged debt instruments. And there's an army of "quants" who spend every day pricing those risks.

The difference is that one of those evaluations can make you money and security risk evaluation can only cost you money. Little surprise they don't want security risks priced.

Re:one-way street

[dkleinsc]

It's impossible to tell someone what the odds are of X being compromised due to Y risk, resulting in Z cost; the best you can do is look for weaknesses and then come up with a plan to prioritize and fix them.

The thing is, there are often ways of quantifying it. For instance, let's say there's a risk in exposing N customer credit cards. Look at what it cost TJ Maxx and some other high-profile victims. That's the Z variable in your equation. Then you can evaluate the difficulty of exploiting the weakness: If you can find it easily on your website with Google, that's high, if there's some obscure combination of weird parameters done just right, that's a lower risk, getting the odds. Multiply the odds by the cost, and that's what you can reasonably argue for spending to fix the problem.

Re:one-way street

[Talderas]

He just wants a blowjob.

Re:one-way street

[Anonymous Coward]

The problem is that neither side wants to do the translation work but clearly the onus is on the people who make decisions educating themselves about what their business actually does.

Re:one-way street

[h4rr4r]

Yeah, they did a great job with that historically right?

Mortgage crisis mean anything to you?

Re:one-way street

[ohieaux]

That was the basis for my comment. Risk is difficult to quantify. Decisions are made on cost/benefit, payback, TVM, ROI or some other balance between costs and rewards. Without a basis for making that equation push to change, change will not happen. I've not been in an organization yet that has infinite resources. With limited budgets, those projects that show return receive funding and support. Those that show a negative balance don't.

Some change can be forced with regulatory compliance and some organizations recognize that changes are critical to stability of the systems that generate, or support generating, revenue. But, many gaps remain. And yes, the field is moving and the rules change - sometimes dramatically. I'm just glad I don't have to make those decisions.

Re:one-way street

[Shoten]

Yeah, they did a great job with that historically right?

Mortgage crisis mean anything to you?

Exactly...and when it comes to leveraged debt and securities, there actually aren't people trying to make them all fail. It's nothing like security, it's far, far simpler. And yet...look what happened even so, when the quants were set loose?

Re:one-way street

[Jane Q. Public]

"Partially true, but not universally so. The problem is more that technical staff speaks in terms of technical risks, while upper management thinks in terms of business risk, and the two are not obviously aligned."

Balls.

If your upper IT management is not also business-savvy, you have the wrong people.

I have run into this personally, and also seen colleagues go through it. It tends to go something like this:

IT: "Mr. Manager, sir: the login system I inherited from my predecessor stores passwords in plain text. This is unacceptable, because it puts the company at risk of liability should we ever be hacked."

Manager: "Haha. Who would bother to hack us?"

IT: "You never know. That's the problem. But in the unlikely event that we ARE hacked, we could be liable because the system is not properly secured."

Manager: "How much will that cost?"

IT: "Mmmmm.... let's see. 40 man-hours to make the code changes system-wide, and 20 man-hours to roll out the database changes. Part of that is to set up a system to send out a mailer to all the users to change their passwords, pages to handle that, and to deal with the traffic that will generate. Say, roughly, $8000 realistically, over a period of two weeks."

Manager: "Haha. Not bloody likely."

IT: "But the company could be liable for millions."

Manager: "It's simply not a problem. Go away."

Re:one-way street

[Casca]

They don't want to hear it, because no executive is willing to put their name on a piece of paper that says they understand there is a risk, and are willing to live with it. We live in a society of blame now, where even the most carefully examined issue and well thought out justification of acceptable risk can be turned into a breach of fiduciary duty and gross negligence.

Re:one-way street

[sjames]

Isn't management supposed to be in charge of figuring out dollar amounts? Aren't they the ones who are supposed to have the mad communication skills?

Re:one-way street

[1s44c]

IT would love to, but upper management doesn't want to hear it.

I find management don't understand these things and will either ignore what they are told or go off the deep end and demand ridiculous fixes.

It's always been up to IT to refuse to do anything that comes with a huge security risk and to compromise on the small security risks.

Re:one-way street

[Moryath]

There are many organizations where it really isn't possible to "work with" security because security policy is implemented by a group of people who don't care what the business needs to get done to make money.

Or where security is trying to do their damn job, while shitwits who don't understand the first thing about security claim they know "what the business needs to get done to make money" while they are really claiming they want their password to be "god" or just plain blank.

In addition, I have never been in an organization where security policies were reviewed to determine if they were still applicable, nor have I been in one where the makers of the rules have asked anybody other than themselves about "what should we do about X?"

Security policies are reviewed all the damn time. The problem is that those who make the decisions don't know the first thing about security. If you have those supposedly "onerous" policies, they were put in place for regulatory reasons most likely (HIPPA, FERPA, etc). And you're damned right, those are NOT negotiable. There's federal law involved.

As an example, we're trying to get a data transfer application that uses a non-standard port to work through our firewall. The current test setup has no data that can even be remotely considered "sensitive" (e.g., test files are "lorem ipsum" or similar).

Ever heard of privilege escalation? Once it is behind the firewall and compromised, it doesn't matter what is "on the test setup", unless your "test setup" is itself entirely separated from the rest of the network (which I highly, highly doubt). Your test setup's ability to be compromised is a problem and not just a "little" problem.

The correct way to test would have been to just open the port with a restriction on the outside IP address, and then we could just use the app with default config (no security, etc.)

Great, until Jody the CFO's secretary opens the "Yay Free Kittens Screensaver App" email from her retarded brother in law and now HER machine is the infection vector for your test setup.

But, because security has a veto on everything,

Want to know why? Because it's not security's job to hold the hands of whiny-ass little bitches like you. It's to keep the company's patents, IP, sensitive records, and other shit that can get you fined by the Feds or put out of business safe. Whiny-ass security incompetent bitches like you are the enemy within and security's been ordered to protect the network FROM you.

Re:one-way street

[1s44c]

The risk of this vulnerability is 2.5 Snowdens.

2.5 Snowdens is what? Nuking a major population center or creating a virus that wipes out a fifth of the world's population?

Normal businesses deal with risk of at most 0.01 Snowden, and that would be accidental death of their entire work force.

Re:one-way street

[arth1]

Upper management are always deliberately clueless about security, unless the company is in the business of security.

This is more true than you know. Being ignorant of something protects them. They don't want to know, because with knowledge comes responsibility. If you know you're vulnerable, and you did nothing, it's far worse than being able to say that you didn't know.
Is it right? Of course not. But I have more than a few times encountered people who did not want to know something because of culpability implications.

Re:one-way street

[JustOK]

It's a log scale

Re:one-way street

[Anonymous Coward]

Hardly.

0.01 Snowdens: You have a security problem, but no one ever blames it on you.
0.1 Snowdens: Some security researchers realize you have a security problem. They talk about it amongst themselves but no one in the real world notices or cares.
0.5 Snowdens: You have a serious security problem that costs your customers a lot of money. Fortunately, they don't realize or care, even though security researchers keep trying to tell them they should.
1.0 Snowdens: You have a massive security problem that requires you to engage in a public relations campaign, but doesn't require any other action from you, since still no one cares. Security researchers start to mention your case as an anti-pattern in technical talks.
2.0 Snowdens: The insecurity is bad enough that customers clamor for you to change things. You are forced update some public-facing documents, though you don't actually have to change anything technical. Security researchers vomit when they hear your name.
5.0 Snowdens: You actually have to make some concrete security improvements. You may have to partially compensate a customer for losses it incurred as a result of your security problem. Security researchers hearing about your case must make a Fortitude save or die; survivors go permanently insane.
10.0 Snowdens: The problem is bad enough that the CEO decides it's worthwhile to spend the money needed to fix the problem. The effects on security researchers are too gruesome to describe here. (Note: No recorded security breach has ever reached this magnitude. The effects are extrapolated based on a theoretical model.)

Re:one-way street

[Anonymous Coward]

This is somewhat how I got started in IT. Back when Novell Networks were still a thing, I was in middle school. I had access to the entire school network (not a big deal, 500 students, maybe 20 teachers). I never did anything malicious, although, I could have. I got suspended for a week after the school network crashed because a teacher once saw I had "a black screen", i.e. a DOS prompt. My parents asked me point blank: did I do it? To which I honestly replied no. Their response was to buy me pretty much any technical book I wanted with the attitude, if you've been accused of something and suspended from school for it, you're damn well going to know how to do it. (The "hacking" I did was merely to dial in to the school admin's computer using Carbon Copy after the admin had finished running the nightly backups).

Re:one-way street

[mlts]

In some companies (mainly seen this in educational institutions), there can be fault finding, "What, there is a vulnerability? Who was the last man in charge? Fire them!"

I've seen many people in IT who stepped up and reported security issues, only to get a target painted squarely into their backs and pretty soon after, shown the door with a black mark for their resume of "communicating to others about bypassing company security controls" or some other tales.

A lot of places will not hesitate to shoot the messenger.

In cases like these, if the hole has to be fixed ASAP, one can send anonymous E-mail to all IT people (through a long Mixmaster chain) about the hole. Then, it will get cleared up quickly, but most likely a witch hunt would ensue internally. Of course, this has a high chance of backfiring since a blamestorming session will soon to follow with someone getting to boot.

Re:one-way street

[DarthVain]

Well done sir, well done.

Re:one-way street

[Anonymous Coward]

I'm in charge of the encryption process at our company, I'm not part of the security team. The business unit is pushing encryption because it's required by law for us to be encrypted. I spent a month testing every known variant of computer and software supplied to me and all worked well. Then we push and 2 problems come up. Users couldn't follow instructions with pictures and big boxes with giant arrows and the second problem was users were having trouble with passwords. So we made it even easier, one password that automatically syncs. Still too hard, they want to turn the encryption off to make it so it's easier for them to log in. Keep in mind these users only have to know 1 password to log in now. Sometimes users just want a reason to complain. The actual break issues that have come up have been below 1%. So please if you require me to follow rules and jump through hoops to get paid, then it's no less fair that you have to follow the law and protect our company data from the outside world. Also your testing set up should be on a segregated network. Not a production environment.

Re:one-way street

[LinuxIsGarbage]

This is somewhat how I got started in IT. Back when Novell Networks were still a thing, I was in middle school.

My F500 company still runs on Netware you insensitive clod!

Re:one-way street

[Anonymous Coward]

Frightening but probably very typical. On the other hand, I work with a small school and I built a dual server cluster with RAID. Everything is duplicated including power supplies and UPSes. They didn't want to go for triple redundancy but at least the old servers are used for off site backup.

Re:one-way street

[kilfarsnar]

And that is the crux of the matter. Risk must be quantified in the units that business decisions are made - dollars. Beyond that, risk needs to accurately assessed to the point of what is the likelihood and not what is possible. Once we know the likelihood and the cost, decision makers will be able to make their decisions.

Ah, but here's the problem: It can't be done.

Explain to me how you will take risk and quantify it in dollars, when the attacks, the attackers and the vulnerabilities are changing over time. Explain to me how you will take the complexity of an environment with multiple critical paths...which will have changed by the time you're done mapping all of them, by the way...and map the vulnerabilities (all of them...you'll need to know this, obviously, and good luck with that) against those, in combination with a full on threat assessment of all the threat actors who may be interested in the organization as a target. Explain to me how you'll actually come up with a probability of compromise for every threat and vulnerability, and a cost for each possible kind of breach. Oh, and since capital planning will be determined using this, you need to predict, with a fair degree of accuracy, how all of this will change over the next 36 months (including guessing correctly about which capital budgets for other business functions will be approved).

This has been tried; it does not work. It costs an insane amount of money to do it, and this is why none of the security frameworks (CMMI, ITIL's security subset, COBIT, NIST SP800-53, etc.) try to do it. That's why you have to instead look at where you are weak overall, and work on improvement in general terms. There's no way to get to discrete numbers when it comes to this form of risk, because there are actual people on the other end of the equation, trying to change the numbers. It's not like most other forms of risk, where the outside cause is non-sentient and fairly quantifiable with actuarial means.

Just do like they did for the bank bailouts: pick a really big number.

Re:one-way street

[Feyshtey]

You're right. Or they bring up a security concern only to get accused of being incompetent for not seeing it sooner.

Re:one-way street

[kilfarsnar]

Doesn't approximately half the population?

Re:one-way street

[DarkOx]

Or, more to the point, they don't understand it even if you try to tell them.

I call BS. I know this is contrary to widely held Slashdot opinion but for the most part people don't get into upper management without know which side of the bread to butter. Sure there are cases where you have the "Vice President of being the CEO's step son" and "Chief Flirt with the Ownership" and its true lots of people are promoted to their level of incompetence; but upper management is mostly as smart you probably are and with better social skills.

If they don't understand its because you talking to them at a detailed level on topic you have lots of time in learning invested in and they don't. If your sentence ends with "... and then after a short no-op sled BAM!" you probably are doing it wrong.

They want to know know about risk. What is likely hood someone could and would exploit the vulnerability. What harm can happen if they do. Then if you get a question like "but I don't understand I thought we had a firewall" You can answer with analogies like; "well we have guard that normally sits up but the front entrance. He makes it hard for people to come in and walk out with stuff normally; but if the latch is left broken on the dock door someone might pull up toss a bunch of product in the back of pickup and drive off before he even get to the other end of the plant to do something about it"

Re:one-way street

[DarkOx]

This has been historically true but working in the security industry I see it chaning. Shit has started to roll back up hill if you will. The data breach laws, in the health and financial sectors, and the realization that the rest of the world now has the manufacturing capability to leverage your IP against you if they do still it in those sectors, has the CXO and board of directors types worried.

They are starting to internalize what these can do your public image and stock price. While the blood sacrifice of some IT guy might been sufficient in the past when the investor gods come demanding an offering it might be only their blue blood that will do.

Ultimately these guys are likely everyone else they want to secure what they feel is theirs. Before that meant putting up really good numbers, and you could also shift the blame for a disaster onto some subordinate if things did not work out. Now that is slightly less true with respect to IT and an interest in solving the problems rather than papering over them is developing.

Re:one-way street

[Anonymous Coward]

That is my take on this as well. I really can't understand as someone who has both been a developer and the firewall guy why you'd want to test a 'protocol' on the Internet. If there really is some reason you can't build a representative test in house why you would not simply have one of the "firewall guys" on the test team so you can get immediate feedback and changes if he is seeing drops due to IDS or odd shaping issues happening like zero windows and things. That way you could actually pin down what does not play well in production environments and maybe do something about it.

Because otherwise what happens is devs deliver some app with kludgey protocol that freaks out IDS devices, or has terrible performance problems with other inspection and shaping etc; but "oh no its release code; can't get changed now" and it ends up needing "exceptions" forever.

I have had this discussion with our software folks too, when they whine "but but but the RFC says SHOULD not MUST, so the NAT/Firewall/Shaper/IDS/Layer7filter/whatever has to allow it". RFC language lawyering is fun and all but fact is everyone everywhere will be happier if you just stay in the 9 dots.

The reality is people do all sorts of "funny" stuff on Networks that make assumptions about what is and isnt normal. People transparently proxy http, they probably should not but they do, don't use 80 if its not suffiencelty http like a web proxy will handle it. People MTIM SSL they really probably should not but they do; make sure you use the system key store for your checking so its at least go a shot at "just working" if they otherwise configure their hosts properly; and again not SSL don't use 443. ICMP all bets off. UDP fine but you probably better send replies on to the clients source port not some other port should firewalls try and impose notions of session on UDP no, but many do. I could go on but,

  If its not working cleanly in our environment, where I know all the details just imagine the fun our customers who likely run alot of the same security toolbox we do will have when its mostly a black box to them; you're gonna love having those calls escalated to you.

Re:one-way street

[elashish14]

And in other !news, management does not have the requisite competencies of their positions.

Seriously, if you preside over IT and don't have the technical awareness to deal with issues like these, you don't belong in your job. Of course, the problem is systematic, because someone put that ignorant dolt in the first place, who in turn was put in place by another ignorant dolt..... recursion.

Re:one-way street

[Tetch]

Oblig Dilbert:

http://dilbert.com/strips/comic/2004-01-11/
"I fixed the Internet"

Re:one-way street

[Anonymous Coward]

Ha i love you're post!

Re:one-way street

[khchung]

And that is the crux of the matter. Risk must be quantified in the units that business decisions are made - dollars. Beyond that, risk needs to accurately assessed to the point of what is the likelihood and not what is possible. Once we know the likelihood and the cost, decision makers will be able to make their decisions.

Ah, but here's the problem: It can't be done.

Explain to me how you will ....

And that's exactly the point. You bring a problem to management, a problem that they cannot simply ignore. So their CYA response is to ask you to do the impossible just so they can then decide what to do. Now since you cannot accurately quantify the risk, it is your fault if anything bad happens.

Of course, it begs the question that if management can only make decisions if everything has been quantified, then why not just replace them with a computer?

Re:one-way street

[Anonymous Coward]

Fortunately I heard such things ahead of time and submitted the security hole I found to my school anonymously.

Re:one-way street

[ArsonSmith]

You seem to have some suppressed sexual frustrations. Are you not getting enough blowjobs?

Re:one-way street

[erp_consultant]

"I call BS" - Clearly you haven't worked in Higher Ed. In Higher Ed executives get where they are because of their academic credentials, not their leadership capabilities. In HE, security risks are only taken seriously if failing to comply affects the amount of government money coming in.

Re:one-way street

[Ice Tiger]

He's the CEO and it's his call, however he's going to wake up to the realities of not planning for something breaking down when it happens. Modern technology is great but doesn't have an infinite life span just yet. :)

Re:one-way street

[mysidia]

Manager: "It's simply not a problem. Go away."

That's not IT failing to communicate risks. That's management not caring about risks.

Except; management hasn't really taken on the risk either --- if they are hacked; he will simply blame the IT guy, and he will be fired for having plaintext password storage.

Sure he had that conversion about it with the Manager, but I will bet the IT guy did not document it, and get the manager to sign off on "not fixing the problem".

Which means the manager will always be able to escape liability for him and the organization by using his subordinate as a scapegoat -- and he can even see that the IT guy gets sued instead of the company; "Good of the many outweigh the needs of the few....".

Re:one-way street

[mysidia]

And just TRY to talk to them about two-factor identification (via cellphones or a swipe-card or something). You will get nowhere because the brainless, Peter Principle, Fail-Upwards recipients of CEO/CTO/CFO jobs will say it's "too much work" for them to comply with.

Maybe the two factor auth on the market IS too much work for people to comply with. I have had a negative reaction from many ordinary people to suggestions of 2-factor auth using Yubikey,Smartcard, Fingerprint, RSA Token, Cell phone, or other. It's all about the inconevnience of having to carry around another key in their pocket; the unfamiliarity of the login process, or the extra time and annoyance people need to take every time they come back to unlock their workstation.

If ordinary people are annoyed by it, maybe it is too burdensome, and security folks looking earnestly towards a promise of "stronger authentication" are full of shit and hurting the business, with added massive hardware costs (All security vendors seem to charge an arm and a leg for any security "solutionss"!), annoyances, frustrations, and costs for everyone?

Re:one-way street

[mysidia]

Security policies are reviewed all the damn time. The problem is that those who make the decisions don't know the first thing about security. If you have those supposedly "onerous" policies, they were put in place for regulatory reasons most likely (HIPPA, FERPA, etc). And you're damned right, those are NOT negotiable. There's federal law involved.

That's complete bollocks. The federal law rarely/never requires a specific security management policy. There are always multiple different ways of implementing the law, or making sure the organization will comply with the law.

Ever heard of privilege escalation? Once it is behind the firewall and compromised, it doesn't matter what is "on the test setup", unless your "test setup" is itself entirely separated from the rest of the network

This is what is called a vague aspersion; FUD; or attempt to create irrational fears. It is not something that just you are guilty of, but something a lot of security folks are guilty of.

Last I checked; weak cryptography in a test system is not a privilege escalation risk.

Now the concept of data transfer from a system outside the firewall, to an internal system on a secured network; is very scary to me. That's the sort of thing that keeps admins from being able to sleepe at night; knowing there's some "special application" that has somehow been given permission to bypass the DMZ and allow directed file transfers to the internal LAN.

This is exactly the sort of thing the firewall is supposed to prevent, and there should be no exceptions; only servers on a DMZ should have any ports whatsoever open, BUT; somehow, some app developer has managed to convince management, that there is an exceptional situation meriting the security of the firewall be totally nerfed, and data allowed to flow into the corporate network with minimal real controls.

This is one of the likely paths that could be used to deliver crafted malicious code into the LAN and open a backdoor.

Put together in the future with other risks; there is a potential for a compromise to be linked to it, AND that's even if the cryptography is fixed.

Re:one-way street

[Anonymous Coward]

This has happened to someone I know. When they were a student at WTAMU in Canyon, TX, they had informed an ISP admin (ARN.NET) of certain vulnerabilities on their systems configuration. When eventually those vulnerabilities were discovered by others and exploited, the "messenger" was accused and even proscecuted of the issue by the ISPs admins who had to save face.

Re:one-way street

[Macgrrl]

I'd say more than half, if you slightly broaden the scope of your definition of a blow job.

Re:one-way street

[intermodal]

You seem to assume a large company. I'm a one-man shop at a small business. I report directly to the owner/CEO/whatever he wants to call himself today. My job exists specifically because he doesn't understand today's technology at all.

Re:one-way street

[Anonymous Coward]

In my company, we are in CYA mode.

Coffee supply delivery was late? Yell at the UPS guy until he signs a form you spent 10 minutes typing up absolving you of all blame.

Project deliverable 158 is late due to X, Y and Z? Yell at vendors A, B and C until they sign forms you spent 10 minutes each typing up absolving you of all blame.

Employee 44 needs a sick day? Yell at employee 44 until he or she signs a form you spent 10 minutes typing up, absolving you of all blame, and blaming employee 44 for becoming ill.

Total time doing CYA activities: 95%
Total time doing actual work: 5%

Re:one-way street

[nabsltd]

You should be testing the application in an isolated test environment and not on the production network. In fact, you could have gone to the firewall guys to install a test firewall in the test environment to iron all of these things out.

This is on a "test" VLAN behind the firewall. Since the firewall is so lightly loaded and such tests don't need any global changes to config (if they did, then that would be a reasonable place to have a very long discussion), there isn't a need for a "test" firewall.

Re:one-way street

[nabsltd]

>That is my take on this as well. I really can't understand as someone who has both been a developer and the firewall guy why you'd want to test a 'protocol' on the Internet

Because when you control all the routers and firewalls, you can change the configs to make a protocol work. You can't do that on the Internet.

Since the whole point of this software is to transfer data across the Internet, we need to test it over a least some portion of the real Internet. Internal testing has already been done, and it works fine when there is no firewall blocking the port. I didn't include this point because I assumed it went without saying.

It is risky even to comment on this

[Anonymous Coward]

It is so risky even to comment on this that nobody is risking it

Re:It is risky even to comment on this

[Z00L00K]

A lot of managers at the top level are there because they have a big mouth and not because they have competence. Not all though - and changes in process is a very scary thing for those that lacks competence because it means that they either have to work for their salary or look for a new job.

You sooner or later will see the difference between managers, and you shall watch out for those that changes job at a breakneck pace and show up with a "new cool gadget" every other week paid by the company while you as an employee has to stick with a three year old phone that works on odd days and with a battery life of an hour.

Holy buzzword Batman!

[guytoronto]

"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?

Re:Holy buzzword Batman!

[intermodal]

They forgot "synergy" and "best practices".

Re:Holy buzzword Batman!

[Stillglade]

Don't confuse a large vocabulary with buzzwords. How would you rewrite the quoted sentences to be more layman without losing any nuances?

Re:Holy buzzword Batman!

[The-Ixian]

"I think we should discuss this offline..."
 
For some reason, that statement bothers me above all others.

Re:Holy buzzword Batman!

[Anonymous Coward]

... will require security professionals to develop new communication skills...

Because getting management to develop new communication skills is just out of the question.

Re:Holy buzzword Batman!

[Compuser]

"However, it's clear from this report that most organizations fail to properly consider security risks when making day-to-day business decisions. Changing this will require security professionals to talk to upper management about security risks in terms that are clearly relevant to overall business goals."

Re:Holy buzzword Batman!

[CanHasDIY]

Don't forget the neo-classic, "vertical integration"

Re:Holy buzzword Batman!

[Stillglade]

The second sentence should probably say "... professionals to change how they talk to upper management ..." to keep the original intention, but your point is well taken; thanks!

Re:Holy buzzword Batman!

[i kan reed]

Oh god, when they say that in person, to your face, and mean use email to discuss it, it's time to shrivel up and die.

Re:Holy buzzword Batman!

[Anonymous Coward]

Thank you. The fact that Stillglade actually thinks that buzzword laden bullshit is a mark of intelligence is a sad commentary on the state of the world.

Re:Holy buzzword Batman!

[mysidia]

In other words: security professionals will have to become a lot more like managers, both in how they think, how they act, and what actions they recommend in response to potential security threats.

Anything

[Anonymous Coward]

Anything which causes extra cost isn't worth listening about, who cares if you get hacked? you just fire the IT staff and restart..

Unless I misunderstand things.

[Impy the Impiuos Imp]

I'm sure Congress will ignore Syria and ever-mounting spending problems and jump right on this pressing issue!

Re:Unless I misunderstand things.

[intermodal]

Well, considering Congress is still on vacation and that far more than 50% of Americans want congress to vote against getting involved with Syria, they may as well work on something else when they get back. Here's hoping for a non-intervention in Syria!

Re:Unless I misunderstand things.

[Anonymous Coward]

Good one!

Note that failures in IT Security in modern businesses is far more likely to cause problems for citizens than Yet Another Conflict In The Middle East. The possibility of PII loss, financial loss and identity theft from business IT Security failures is huge.

However, effectively addressing this issue has 2 huge roadblocks:

1) If executive management addresses it, it may add costs that reduce the profit in the next quarter, so they won't help since that affects their bonuses.
2) There's nothing that gummint can do: More audits will only cause excessive costs to businesses with no possibility of actually helping the problem.

Welcome to the new millenium: You're ON YOUR OWN!!

Re:Unless I misunderstand things.

[Impy the Impiuos Imp]

DAMMIT wrong thread!

This was supposed to go in the helicopter RV kills guy thread.

nothing to see here, move along folks.

Re:Unless I misunderstand things.

[hedwards]

I don't recall being asked what I thought about that. I remember when more than half of Americans thought getting involved with Iraq was a good idea. Or when they thought that Obamacare was a bad idea.

Just because more than half of Americans want something, doesn't mean it's a good idea. What's more, thanks to gerrymandering, it can take nearly 75% or so to actually ensure anything gets done.

Re:Unless I misunderstand things.

[intermodal]

If I needed an opinion on something, I certainly wouldn't pick you to get them from.

Re:Unless I misunderstand things.

[Lazere]

So, congratulations on accidentally generating real discussion... I guess.

Re:Unless I misunderstand things.

[hedwards]

You mean the real world? I must say that I can't blame you, 'tis a horrid place.

Re:Unless I misunderstand things.

[Impy the Impiuos Imp]

I do troll from time to time. I guess my powers are so great I even accidentally

They don't want to know (IME)

[Anonymous Coward]

My profession isn't sys-admin, but I take care of that at my office. (SO, 6-8 people)
Both my boss and colleagues use super weak password (tom101) in spite of me asking them to be serious.
I warned the system was insecure, but was never given a moment to work on it.
At some point I just had to wash my hands of it, I'm not even paid to be responsible for it.

There is a limit of how many times you will tell people the sam thing, especially when they don't care or get annoyed because it requires an effort from them.

It seems management don't want to spend ressources on a problem they don't (want to) understand, preferring closing their eyes.

Re:They don't want to know (IME)

[bobstreo]

My profession isn't sys-admin, but I take care of that at my office. (SO, 6-8 people)
Both my boss and colleagues use super weak password (tom101) in spite of me asking them to be serious.
I warned the system was insecure, but was never given a moment to work on it.
At some point I just had to wash my hands of it, I'm not even paid to be responsible for it.

There is a limit of how many times you will tell people the sam thing, especially when they don't care or get annoyed because it requires an effort from them.

It seems management don't want to spend ressources on a problem they don't (want to) understand, preferring closing their eyes.

But in fact, you and they may be liable for anything that goes wrong.

Re:They don't want to know (IME)

[bobdawonderweasel]

I feel your pain. However, if you are under HIPPA or PCI then there are real penalties that can come back on you (if the management weasels can push the blame on you after a breach).

Re:They don't want to know (IME)

[nabsltd]

Both my boss and colleagues use super weak password (tom101) in spite of me asking them to be serious.

Why is this an issue?

Seriously, the point of security rules is to keep data safe while still allowing the business to function. If it's a small office with no access from outside the local network, then maybe password strength isn't important. Maybe the real threat would be someone who is already inside the company, knows nothing about hacking, but could type in the long password they find written on the sticky note because the user couldn't remember it.

Until the entire system (by which I mean the whole company) is analyzed to create a weighted list of threats, there is no way to know if enforcing strong passwords is worth the trouble. That threat might be 192nd on the list, where only the top 12 are considered more than "low risk".

Re:They don't want to know (IME)

[Anonymous Coward]

"Hey boss, here's you're new password: 7shw-ahdy5y.

"Yeah, it's a bit more complex than usual, sorry about that. We had to download the new v3.05 patch for IP-Gram 2.0, which monitors the 3.6 gigahertz fretznostat. Without it, we won't be in compliance with the IAAA-3 rules allowing us to connect to the Internet. Anyway, they have a new mandatory password complexity scheme. I tried to set it back to PASSWORD1 like you like it, but it won't accept it.

"You think that's bad, the readme on the beta for version 3.06 says that it will enforce monthly password changes. I'll see how long I can put that off before I have to install it. Meanwhile, I'll see if there is some alternative we can use; I've heard of this thing called Linux that may work better for us than our current WindowsME server..."

Blind them with technobabble. They won't understand you anyway, won't remember what you tell them and so long as it looks as if you are working towards their interests won't get upset at you when you force better security practices on them. I mean, it's not your fault that the w

Just don't get caught at it ;-)

Re:They don't want to know (IME)

[Anonymous Coward]

The company will still get rid of you for one reason or another. I reported a security issue, fixed it, got an "attaboy" and two days later, let go. It's been over 90 days and I still haven't heard any disclosure from them.

dont blame us

[nimbius]

I for one spend a sizeable chunk of time trying to explain escalation attacks and SSL issues to my boss, in the hopes that at some point he conveys pertanent information to the upper echelon and secures the funding i need to make things better.
sometimes these are extremely technical problems, so you shouldnt expect me to ensure you understand every minutae before you tell the boss. Sonetimes the problems are caused by us, and thats okay, but hiding them from upper management to ensure your team looks good is so counterproductive it hurts. other times the problems are with existing services that if addressed would cause blocking issues for major corporate goals for the year. not telling the bigwigs about this is sabotage at best. Finally, sometimes upper management just doesnt give a shit. problems like database encryption would slow down the final goal of getting the new cloud widget going, so despite our firm 'fix it now' policy the guys with all the power basically ignore their own mandate and say 'fix it later.' six months later when our widgets get hacked, we get reamed for not fixing the DB issue when we instead had to allocate too much time developing more new features for cloud widget. At this point we just get more myopic, often times ignoring cloud widget entirely in pursuit of fixing ancientDB.

Features are priority #1

[Anonymous Coward]

Security isn't something that anyone wants to spend time and money on in business.

The bottom line is, if you put a fancy security system in your house and no one ever though about breaking in to begin with, you've wasted time and money.

Re:Features are priority #1

[someSnarkyBastard]

And yet you are required to have homeowners or renters insurance to have a house/apt. By your logic, if your domicile never gets burgled or burns to the ground then all that money you are paying for insurance is money wasted.

Security systems of any kind are reactionary, they only act if Something Bad happens first. In other words, you don't WANT to actually use your security system or insurance, you just want them available and standing by to mitigate any damage that comes from whatever Bad Thing happened to disrupt your home.

You may consider that money wasted but when you compare the cost of insurance or a security system against the cost of a home invasion or fire you are actually saving money. It's all about measured and accepted risk. If you truly believe that money is wasted then don't pay for it; just don't come crying to me when your house burns down and your have no way to rebuild or pay off the bank loan on the pile of ashes you used to call a house.

Re:Features are priority #1

[Anonymous Coward]

Security isn't something that anyone wants to spend time and money on in business.

The bottom line is, if you put a fancy security system in your house and no one ever though about breaking in to begin with, you've wasted time and money.

Seriously, you are an idiot. How do you think insurance works?

Re:Features are priority #1

[Anonymous Coward]

"And yet you are required to have homeowners or renters insurance to have a house/apt."

Where? Certainly not in California, Oregon, Washington, Connecticut, Ohio or any state I've ever lived. Unless you have a waterbed or a pet.

Re:Features are priority #1

[someSnarkyBastard]

Texas, one of the hardest-core red states out there, for one...

Re:Features are priority #1

[mysidia]

And yet you are required to have homeowners or renters insurance to have a house/apt

Why do you say that? You have the option of not buying either. You could bank the premium you would have spent on that; or form your own insurance company to write your policy and pay the premium into that. On average, you will probably save money after enough time passes without any of those events happening.

In the worst case you don't, BUT insurance is always priced such that the insurance company expects that on average, the premium will be much higher than the expected costs of insurance claims during the policy term.

Spoon fed

[barista]

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.

Re:Spoon fed

[intermodal]

That's perfectly reasonable in an organization with people who will actually attempt to understand what you are saying. I'm in an office where about 50% of my users, despite my taking the time to explain and demonstrate the proper methods for restarting or shutting down their computer, still insist upon holding down the power button without closing anything until it just turns off.

Re:Spoon fed

[Anonymous Coward]

How long does a soft powerdown take? I've seen them take 5-10 minutes (with a 50% success rate). At home they take about 30 seconds. My solution is to put critical documents on sshfs, run sync, and pull the plug. It has no respect for my time, I have no respect for its shutdown procedure.

If you've worked hard to make proper shutdown fast and reliable, you have my sympathies. If not, I tend to side with your users.

Re:Spoon fed

[intermodal]

The reboot on the machines in question is extremely fast, actually. The problem is, they simply don't care enough to remember the procedure. I'm dealing with an extremely non-technical crowd.

Re:Spoon fed

[Anonymous Coward]

The reboot on the machines in question is extremely fast, actually. The problem is, they simply don't care enough to remember the procedure. I'm dealing with an extremely non-technical crowd.

They have to remember a procedure? Anything beyond 2-3 clicks seems excessive for such an everyday task. Why haven't you scripted your whole procedure?

Re:Spoon fed

[intermodal]

They're on standard Win 7 Pro. I've even made the start menu's "shut down" button into a "restart" button. Two clicks. That's it.

I think you're vastly overestimating my users.

Re:Spoon fed

[Darinbob]

I've seen cases of bad security info sent out. Ie, company wide malware alerts for something that was wrong in the first place, or IT people repeating an internet rumor to the company. Another reason employees may ignore the alerts (especially programmers who understand this stuff better than IT).

Re:Spoon fed

[mysidia]

Another reason employees may ignore the alerts (especially programmers who understand this stuff better than IT).

You mean arrogant developers who falsely believe they have a better understanding of current risks than IT?

Obviously sending out company wide computer alerts, should only be done with IT's approval.

or we tell them about it and get fired

[Anonymous Coward]

And get fired for not fixing it, because the jackholes didn't give us the budget to fix it. Guess what jerky, we're just simply not going to tell you if you won't give us the means to fix it anyways.

What management says is:

[CmdrEdem]

"Don't worry about it, it's not that serious."

Well, you are wrong, your head is up your ass, and this kind of stuff is why guys like you hire guys like me, even if you don't know that. So, let the IT dept. do it's job, dammit!

Re:What management says is:

[someSnarkyBastard]

CEO response: "You are not a profit center, you are a cost center; therefore you a necessary evil that we tolerate only as much as we absolutely need to. You get in the way of business, of making money, of paying your bloody paycheck, and expect me to thank you for that and say "more please"? Get the fsck out of my office, you're fired!"

Re:What management says is:

[Anonymous Coward]

CEO response: "[...] Get the fsck out of my office, you're fired!"

A CEO cannot pronounce "fsck".

Re:What management says is:

[someSnarkyBastard]

probably not but anyone here will automatically run an inline "sed s/s/u" while reading it

Re:What management says is:

[Anonymous Coward]

At least companies that think that way will not survive long. Sucks for the people that work there, but anyone that sticks around at an abusive denalist company culture gets what they deserve.

Why communicate with business...

[Anonymous Coward]

...when business is *ALWAYS" right when it comes to decisions...?

Shoot the messenger

[Anonymous Coward]

Yes, I did stop communicating security risks eventually. I'd say I stopped after the 10 or 20 thousandth 'So what?' from management.

Re:Shoot the messenger

[Anonymous Coward]

I pretty much stopped after "well, we can fix that later"... and, well, after the 20-point (numbered) email I sent to the boss of all the problems in the environment (pretty much all security holes), him saying he'll have to 'spin up a project' on it... 6mo's later, having one of my coworkers bring up one or two of them him saying "oh yeah, P sent me a list like that, P can you send me that again?" (mind you, it *should* have been in his outlook? I mean, I have an archive(s) of every single email I received or sent at that job, in almost 10 years before I got laid off a few months back, burned it to something like 4 DVD's)... but ok, I sent it to him again... 6mo's later, after 3 applications get hit by a security review with the same problem (only because they were important and got reviewed, all 200+ application servers we had mostly had the same holes because we couldn't possibly have fixed them before building the env - like I originally suggested years before), I mentioned that was on the list I'd sent him "last year" (twice actually), in a meeting with both him and *his* boss, both of whom asked me for that list... ... when I left it'd been over a year since the 3rd time I'd mailed that list out, none of the problems had been fixed except for a couple of apps on a "one-off" basis (because they got audited and failed security reviews)... so out of 200+ app servers, maybe 10 are fixed, in at least 3 years since I mentioned all the problems (well, and most of which I mentioned when we were planning on building the new env to migrate all the apps into, but was ignored on there, so it was well over 5 years for a chunk of them).

Yup, I eventually just gave up on bothering... or, well, I still mentioned it from time to time... but I was the 'thorn' in the bosses side and thus got laid off because I brought up problems and he didn't want to hear about problems. I'm sure all the same security holes are there, in fact when I left they were designing the 'next iteration' of the app server environment (all new servers, 'internal cloud', and nobody wanted to hear about trying to make sure security holes were fixed (or the ones we knew about) before building it and launching/migrating 200+ apps into it).

Security = Liability

[sinij]

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.

Re:Security = Liability

[Anonymous Coward]

No, it's not a language barrier. The problem is that techies cannot tell management what the management does not want to hear. Even if the techies translate perfectly the message "this will cost you $$$ but it MIGHT save you $$$$$!" simply don't work no matter how true the message really is.

Re:Security = Liability

[Anonymous Coward]

Management do not want to hear about unexpected costs, it's IT's job to budget for them. Security in the work environment has been required since Microsoft became a major player. They have always been plagued with virus problems and trojans, going all the way back to pre-networked systems, with infections being passed around on floppies. Having to deal with this outbreaks, the required software updates, the protection suites updating too. It's all been there since the 1980s.

Re:Security = Liability

[Anonymous Coward]

Annualised Loss Expectancy
Annual Rate of Occurrence
This is my mantra, a mantra for me.

Re:Security = Liability

[CanHasDIY]

"Well, look, I already told you. I deal with the goddamn customers so the engineers don't have to!! I have people skills!! I am good at dealing with people!!! Can't you understand that?!?

WHAT THE HELL IS WRONG WITH YOU PEOPLE?!!!!!!!"

-- Tom Smykowski

Re:Security = Liability

[endus]

"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".

Um.

This sounds a lot like risk management.

Risk management is for COMMUNISTS.

Never do a risk assessment when you start a new project, it will just bring up uncomfortable information and make everyone feel sad. :(

Re:Security = Liability

[nabsltd]

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".

Unfortunately, the average security person will vastly overestimate both the severity and the chance of a particular threat coming to pass, and thus will always suggest that X, Y, Z, A, B, C, and the entire alphabet including lower case simply must be done to avoid billions of dollars of damage.

Re:Security = Liability

[imikem]

RIAA, is that you?

Re:Security = Liability

[sinij]

Yes, but this site is read by "average security persons" and I am tailoring my language to something that can be understood. Saying "this cost more to fix than insure", or "we are covered by contracts from this liability", or any other response that does not include "lets fix it all, right now" is usually not well-received. :)

Re:Security = Liability

[dowens81625]

On the other hand if the Company already has a Disaster Recovery plan in place.

1. - Company XYZ was pwn'd
2. - Pay the IT lackies the overtime to spend the next week rebuilding and restoring from backup tapes.
3. - Call the Insurance company and have them write checks to customers for breaches in contracts.
4. - Have Public Relations issue a statement apologizing for the data leakage / loss / comprised whatever.
5. - Call Advertising and have them start a new campaign around a "They took us down but we get up again" Slogan.
6. - Raise prices and budget to fix the issue next year.

Oblig Dilbert

[PPH]

here.

Re:Oblig Dilbert

[Anonymous Coward]

Got that in xkcd form?

Re:Oblig Dilbert

[Opportunist]

We actually did something similar to a boss back in the days. Oh yes, good times.

Re:Oblig Dilbert

[Anonymous Coward]

http://dilbert.com/fast/1996-05-02/
Fast. Dilbert. Fast. Dilbert Fast.
For not stupid people.
People who use Unix/Linux.

Unlike you. Moron.

You talk about it, then they have to do something

[Anonymous Coward]

If you discuss security issues with your upper management, then they think THEY have to do something about it - and ususally it is not the thing and far worse than what you were hoping for.

So the best route is to say 'don't worry, we got it covered' and get what you can done without having to get them involved.

ROFL

[lightknight]

Is....is super lie...

There are many issues that IT attempts to communicate to Senior Management, but, for a variety of reasons, go unhandled. We've tried communicating before...and people said "Shutup, you're talking too technical, you need to speak business," then it became "Shutup, every week there is some sort of thing that needs attending to..."; so, after a while, those reports start getting filed in the garbage can immediately after they are printed, since that's where they end up anyways.

It's only later on, when something has gone terribly wrong (imagine a large kingdom having been run into ruin by the last dozen or so kings...), when there are so many things going wrong all at once that duct tape and shoelaces can't fix things, that Senior Management may wake from its slumber, and ask "What the hell is going on in this company? Why is it taking forever to get new projects done, and old projects are requiring constant intervention just to keep afloat? Why are we leasing buildings that we used to own? How badly mismanaged have things been that the former masters of the household are now its servants?" And that's when Senior Management begins knocking on Accounting, Legal, and IT's doors...if they are still around...and asking, "You are the sensory organs of this company...you deal with the day to day running of operations...why are we bankrupt? Did we lose a major lawsuit? What happened? Accounting, why are we in the red? IT, you handle information on a daily basis...what have you heard?" And for companies that have outsourced all of their IT, Accounting, and Legal operations...well, just getting a hold of someone, who is very unhappy with your delinquent bills, can be trying.

So, what you're seeing now is Senior Management having woken up from a long hiatus, and wondering who made what decisions, and why everything is so wrong.

It's just in the way you present the problem

[MRe_nl]

This usually works;
"Em, sorry to interrupt, but there are some policemen here?
They say they need to speak to you about some irregularities in the pension fund."

http://www.youtube.com/watch?v=UxVivkXUfdU

Terminology

[EmperorOfCanada]

Every day I look at my server logs and see all kinds of "attacks" I'm not sure 5 minutes go by without another wp-admin attempt. I suspect that these are probing known easy attacks. So if I were running IT for a company I could make it sound like this was trench warfare WWI style. It would almost be funny to have an air raid siren going off every time one of these attacks came and having a fire pole for the Admins to slide down.

Seeing that these various "attacks" have various goals it can be hard to even define "Penetrated" If their goal is to scrape all the content from a site and they succeed, or if they wanted to get past the spam filters and post something spammy. Then should that be something you alert everyone about? It starts to become clear at a certain point such as the attacker logging in with root access. But what about a spam post that managed to have some active javascript that popped up a casino ad? Or an SQL Injection that resulted in a spam post being approved? SQL Injection is bad but spam is just another day in the office.

Then you have other fuzzies. DDOS attacks that slow things down. DDOS attacks that slow things down that give a competitor an advantage (such as slowing down a brokerages trades stratigically) or a DDOS attack that simply requires a new server (or 10) so you stop caring about it?

Up to a certain point what constitutes a security problem can be very fuzzy. In theory if you have a weak honeypot machine that when attacked cuts the intruders out of the rest of the network you might have an awesome strategy but could be reported(by some auditor looking to get the contract) as having a "weak link" machine that was woefully under-secured and regularly compromised by intruders unknown.

Re:Terminology

[Opportunist]

What constitutes a security problem is actually very concrete: Whatever your CISO defined. That's part of his job and he better do it. He will also have procedures ready to deal with security problems.

If he does not, take him, fire him, hire someone else. He's worthless.

Re:Terminology

[EmperorOfCanada]

If your organization has a person with the title CISO then your organization is a creaking rusty bucket of stagnation. I had to look up what a CISO was. The description of a CISO is a tiny tiny subset of what the head of IT or the chief Admin should be doing. But giving it the title of CISO makes it sound like the NSA.

A CISO is like in the early 70s when airplanes had engineers in addition to the pilots. In the 60s keeping the engines running and whatnot was hard. But computers could do the work by the 70s so the pilots unions fought to keep them. But this is one of the areas that the newer nimbler airlines cut costs. They only bought airplanes that needed two in the cockpit and eliminated the need for the engineer. But some airlines stuck with them. Pan Am; remember them? The other bloated airlines basically had to go bankrupt one by one to get rid of them. It wasn't that the engineers bankrupted them but that having bloat like an engineer was a symptom of a creaking, rusty bucket of stagnation. I am willing to bet that a high-functioning CISO would be the primary driver of policies that drive the best employees right out of a company "No you can't have an iPad as we haven't reviewed the security implications." "No you can't run apps on your smart-phone until we have reviewed them." "No you can't have your own printer as you might print company secrets."

Re:Terminology

[Opportunist]

A CISOs responsibilities are neither that of a CIO (the head of IT, usually) or the head admin. He usually comes closer to risk management and process management than he actually comes to IT, despite the name and despite being usually positioned somewhere close to the CIO in the organization of a company. Often, you find him somewhere underneath CEO, CFO and CIO. In descending order of sensibility, IMO. It highly depends on the company how he is used, but between security processes and risk assessment he is often used as an in-house consultant for security issues, to write the security parts of specifications for software development, to produce silly, meaningless business ratios for upper management and, yes, unfortunately as the naysaying scapegoat whenever management doesn't want to give you something. Although one has to admit a lot of CISOs do it themselves because it's simply easier to say no than actually do their job, i.e. finding out how to make it possible in a secure and sensible way.

Management doesn't care about the long term

[Anonymous Coward]

In over twenty years I have yet to work at a company that gives a poop about long term concerns like security. Oh I'm sure they will work themselves into a lather when a breach actually happens but after the temporary patch work hacks are put into place then it's back to biz as usual. Disturbing and sad reality.

Re:Management doesn't care about the long term

[Opportunist]

Security does have incredible short term effects. If your R&D papers that you worked on for months get out a week before you have them wrapped up to file patent, you may rest assured that the stock market will feel that earth quake.

Of course not.

[nine-times]

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.

Re:Of course not.

[endus]

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.

Exactly right.

Security professionals have had to be budget-minded for a while now. We're not telling you this because we want to bankrupt the business, we're telling you this because it is a reasonable precaution to take, in line with standards and industry norms, and will save your ass and pay for itself 100x over if there is a breach. People view their own internal security department as the enemy, rather than someone who is on the same side trying to get people to do things properly. We get that there's a margin and a budget, but if you always decide in favor of, "get it done now, as cheaply as possible, we don't have time to do it right" eventually it will catch up with you.

Re:Of course not.

[Anonymous Coward]

Exactly this. Its totally not their problem because they don't understand it, and you do (even when their actions are the security risk). Because you know about it, it is your responsibility.

So, it isn't that IT staff don't communicate problems. They do. The issue is that no-one listens.

Re:Of course not.

[thoromyr]

there's another option to the two you present: IT-related legal risk and liability (it isn't always technical, even if it falls under IT security). I got an out of band compliment for an explanation I gave to management after they insisted we do something wrong/illegal/risky and I laid out the reasons why we should not -- apparently I got the point across but *management just didn't care* and we were instructed to procede.

Seriously: I was complimented for clearly communicating the risk and liability, and at the same time they didn't care. If it weren't for the former I could understand the latter. Bizarre.

Re:Of course not.

[nebosuke]

The example you gave, if true, is a classic demonstration that IT management does not understand their business, not the other way around.

First, while you may want to approach a person directly to give them a friendly heads-up as a first step, the basic thing IT management is supposed to understand is that a user having weak passwords is not so much a risk to that user but a risk to the business. If a user ignores your friendly heads-up, or the problem is more widespread than 1 person, the next step is to go to the person responsible for that part of the business. Now, you don't have to be a douche and call out the specific individual(s) in question, but you then tell that person that there is a systemic risk to their operation because X% of users (or alternatively, a few users with extensive access rights to critical systems) have weak passwords that all appear near the top of /-/@xX0r brute force password dictionaries.

The key thing that even moderately competent managers (IT or otherwise) understand in these kinds of situations is that you have to put the decision (and relevant information) in squarely in the hands of the person accountable and responsible for the issue. In this case the issue is not that someone has a weak password that might result in someone messing up their My Documents folder, it is that weak passwords are a risk to the business. If a bank comptroller's password is 'password', that is not a problem-waiting-to-happen for the comptroller, it's a ticking timebomb for the bank.

In your example, you do not put the decision to act (or not act) in the hands of the account owner, but in the hands of the account owner's business unit head.

Security and IT issues in general tend to get short shrift in many business (at least in my personal experience) not so much because non-IT/non-technical managers are stupid, but because the IT managers lack even basic competence relative to the second half of their title.

Re:Of course not.

[Anonymous Coward]

No you're right. We should adopt the same approach my organisation does. You have dozens of passwords, each of which have oddly different security constraints and forced expiry every 30 days or so. They also lock out if you get them wrong 3 times.

So if you change a password, some people change all of the accounts at the same time that they remember. Of course this is a coin toss, since the new password already changed on 6 systems doesn't pass on another - maybe you have a character repeated or NOT ENOUGH CAPITALS (real message).

So people write them down.

Re:Of course not.

[nine-times]

the next step is to go to the person responsible for that part of the business.

And what if the offender is the CEO? Ah, see, there's the big problem you're failing to account for. Sometimes it's the big muckety muck head-hancho who just doesn't seem to care, and you have no one to appeal to. Or even if it's not the CEO, do you really want to try going over the head of some executive to a higher-level executive?

The thing is, I think your example shows that *you* don't understand business. Lots of this stuff is about politics more than it is about technology or security. If you want to succeed (or at least avoid getting fired), you'd better learn to pick your battles.

Salted hash.

[Anonymous Coward]

Deal everybody (IT and Management)

Never use anything that is reversible to store passwords. Salted hash. Always.

IT Staff vs IT Security Staff

[Anonymous Coward]

There is a big difference there. IT Staff does one thing and IT Security Staff does another. They must work together though. As a malware remediation consultant, I can confidently say 95% of the organizations out there (mostly small to medium sized ones) do not have any comprehensive understanding of good security procedures or what to do when they are compromised. No clue. What-so-ever. This goes way beyond complex passwords and VPN servies. Most organizations that don't understand IT security, or have a department or person focused on it, have no clue they are infected until someone else comes and tells them. At which point, they have no clue what to do. Because they don't see the risks, they don't educate their management to the risks. As a result, they never get the funding to buy tools and equipment to help keep their networks secure.

The most successful organizations I have helped actually have the C-level guys throw special happy hour celebrations when they catch a spearphishing email and dont click on the link, or something else along those lines. This only came after they had a "hundred million dollar" breach and learned a very hard lesson.

Re:IT Staff vs IT Security Staff

[arth1]

There is a big difference there. IT Staff does one thing and IT Security Staff does another. They must work together though. As a malware remediation consultant, I can confidently say 95% of the organizations out there (mostly small to medium sized ones) do not have any comprehensive understanding of good security procedures or what to do when they are compromised

Most small to medium sized businesses don't have separate IT staff and IT security staff either...

Re:IT Staff vs IT Security Staff

[Anonymous Coward]

Or even IT staff at all.

almost all said "too technical". Wrong words, then

[raymorris]

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?

Most executives don't micromanage

[Anonymous Coward]

There are probably thousands of potential new risks per day for all applications within a company. Executives want a summarized one sentence status of security and not a detailed list of possible risks. It is IT/security's job to weed out noise, then prioritize/evaluate risk. After that action is determined.

ca-certificates

[Anonymous Coward]

I hope you all saw the ca-certificates package that was just pushed out. You installed it without looking, too, didn't you?

"Please note that Debian can neither confirm nor deny whether the
certificate authorities whose certificates are included in this package
have in any way been audited for trustworthiness or RFC 3647 compliance.
Full responsibility to assess them belongs to the local system
administrator."

It takes HIPAA or similar regulation

[SkimTony]

Management won't listen to anything regarding security until there's a personal fine associated with it. In fact, ignoring IT's comments allows them to claim ignorance. If you want upper management to pay attention to security risks, make them liable. Until then, IT is just another fall-guy when stuff breaks.

Re:It takes HIPAA or similar regulation

[someSnarkyBastard]

That's why you make any warnings or recommendations in writing so that there can be a paper trail you can point to and say "I warned them about this, they chose not to act on my warning, Ergo they're liable. They had the authority to take the corrective measures that I suggested but chose not to, ultimate fault lies not with me the messenger but them the executor"

Re:It takes HIPAA or similar regulation

[ImOuttaHere]

Doesn't matter. If the execs are aggressive, they'll lay you off for "not getting with the program." [actual words from one exec I knew] Do you run the risk of not being able to put food on the table? Or do you play their game by their terms and live to work another day?

Re:It takes HIPAA or similar regulation

[someSnarkyBastard]

If the exec is aggressive and will fire you for not "getting with the program" then politely bring it to their attention and then shut up and abide by whatever decision they make. They want to be The Decision Maker(TM)? Fine, let them, just make sure your ass is covered when the defecation inevitably interfaces with the oscillation so that they can't throw you under the bus to save their own hide (or at least make it a touch more difficult for them to do so).

Re:It takes HIPAA or similar regulation

[HiThere]

HIPAA hasn't gotten MSWind off of Doctors computers, or off of the Medical Insurance company computers.

If a law that won't be enforced is passed, it's just another thing that the powerful can use against their political enemies.

Re:It takes HIPAA or similar regulation

[SkimTony]

HIPAA is a tool that hospital IT departments can use to make doctors use passwords (at all: if they weren't required, most MDs would never set a password on anything) and at least think about how their data is stored and accessed.

Will some of them still put patient data on DropBox, because "it's easier"? Of course they will, even if Legal tells them it violates ten policies and statutes and IT blocks access to DropBox, Google Drive, MS SkyDrive and iCloud. But it stands a chance of keeping maybe 50% of them following better practices, which is a huge improvement.

Mod parent up.

[bussdriver]

Exactly what I was going to say, but I only had 5 years in IT long ago. Most the nature of IT is unlikely to change; the big issues are rarely technical in nature... people and culture change so slowly it seems almost static relative to technology.

I would add the problem with management is they often are short sighted (except the founder) and do not want to invest in the hypothetical. They don't want to comprehend enough to actually be able to weigh the risks in their "thinking" on such matters - if you make the decisions for them they are OK as long as they don't become aware of it.

They fear reprisal.

[mistaryte]

In these times, they don't feel that there's a "disconnect between layers of management". They fear reprisal for exposing their bad security.

Words the management understand.

[Anonymous Coward]

schedule, budget, (on , off, ahead)
headcount

anything technical is blah blah blah, until one of the words above is mentioned.

and quality is given lip service at best

security is pasted and spackled on at the last minute

signed, a unix/open systems deployment veteran with 20 plus years of putting out running solutions despite management

and currently NOT employed, (tired of beating my head on wall in frustration)

getting a BOFH retooling refresher course and shopping for a bigger tape vault

Grass roots

[Princeofcups]

The only way I've been able to implement proper security at any site has been from the ground up. You find a couple of developers or application support folks with a clue, and get their systems and processes into shape. At the same time, streamline and increase stability. Hopefully other teams will see the benefits of your changes, and follow suite. The only security that comes from on high is security theater, e.g. PCI compliance auditing, which never addresses any real security issues, only check boxes to justify the auditor's fee.

Yes, we do but we do it like this

[sandbagger]

"This e-mail is about my _________ concerns. It is my understanding that I am not funded to replace _________ with the latest version due to budget concerns. As such, I will leave _________ at its current version, ___ until it is reviewed during _________. If this is incorrect, please reply."

"6% of $1M loss = $60K, can be avoid for $4K"

[raymorris]

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.)

Re:"6% of $1M loss = $60K, can be avoid for $4K"

[jeti]

But how can we assess the probability of a successful attack? Since most companies choose not to disclose breaches, we don't have meaningful statistics to base our estimates on.

Re:"6% of $1M loss = $60K, can be avoid for $4K"

[thoromyr]

That is a real problem. And, honestly, I don't think there's a large enough set to make such statistics all that meaningful to begin with. But what you can do is to rate against other risks. Don't say its an exact percentage, break it down into something more like 99% (almost certain), 75% (ilkely), 25% (possibly) and 1% (unlikely). Notice I left out 50%... It might be worth adding in a (0.01%, highly unlikely) but the point is to emphasize the label, not the percentage. Don't claim it as an actual percentage, just a generalized expectation. If you *want* to be mathematical about it take a starting point (say 99% for the "highly likely") and treat it as z scores moving perhaps two standard deviations for each category with the basic idea of keeping a large separation between categories.

The percentages can be used to do math as suggested before hand, but by having clear separation between categories it helps whoever is being communicated to grasp it.

It isn't just the probability of the event, however. Usually there's no clear idea of the cost. I recommend the same approach: divide into general cost categories and put them where it makes most sense. All of these decisions are made easier by having fewer choices and less hair splitting. Essentially you are accounting for the imprecision of the metrics even if you had the numbers. What cost one company of comparable size $1M might cost you $2M or $0.5M. Too many factors and too many ways to count the costs.

I'm not saying to just make the numbers up: there should be some clear reasoning for why picking a category. But, again, it gets easier when you aren't busy hair splitting.

Re:"6% of $1M loss = $60K, can be avoid for $4K"

[dcollins]

The truth is that those probabilities are just totally fabricated from whole cloth. Now on the one hand, it's true that business managers go through the day making decisions in exactly that way all the time. But engineers are more likely trained to base decisions and declarations on actual hard data (with several places of accuracy), and the cognitive dissonance of that same person just inventing numbers to win an argument may be too much to bear.

Re:"6% of $1M loss = $60K, can be avoid for $4K"

[Darinbob]

But that needs to get communicated up the chain. Ie, the person that knows about this is at the bottom of the food chain (or slightly above it, but only one slip up away from being on the help desk). Then the manager has to be told first, the manager probably understands the issues though. Then the mid level manager needs to be told, smaller chance of that manager understanding. Then maybe a mid manager above that other mid manager. Then finally you get to the CIO or VP, who will not understand that information at all. And only then does the CEO get informed.

The problem is that people talk about "IT" as if it were one person. "IT" is almost always a large and disfunctional organization full of clueless people with a few clued in people near the bottom trying to stay out of the way of flying bullets.

Anyone wondering why?

[Opportunist]

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.

Re:Anyone wondering why?

[petes_PoV]

The person who reports the finding gets the blame.

Also known as "shoot the messenger". It's a common problem throughout the world, that the person who reports a problem (security issue, software bug, licence lapse, theft) gets tarred with it. A lot of management actually promote this way of dealing with issues as it keeps the number of fault reports down - which they get measured against and rewarded for doing.

The only way this can ever, in my experience, get resolved is by having QA as an entirely different management structure: outside of software development, hardware, design, testing, production, <whatever> So a problem does NOT go through an individual's standard reporting structure but through an expedited route, up to vice-president / director level.

Managers hate it, as it removes from them control over their own staff. But it can work by anonymising reports and disassociating individuals from issues. But it needs a strong QA team to resist the pressure for witch hunts and from sales, who see it as a road-block to getting stuff to market quickly

Re:Anyone wondering why?

[Darinbob]

Problem one is not unique to security. That happens everywhere. You report a problem and it gets filed under the list of things to do before the universe ends. If a task is not on the list of deliverables then there's no motivation to fix it. And usually nothing is on the list of deliverables unless it's revenue generating (which means nothing IT does fits on that list if you're not a web company). Sometimes it does become important, but it often requires having things like HIPAA or a regulatory compliance officer.

Second issue with blame-the-messenger is very similar to the issue of the person who reports the problem finds themselves in charge of fixing the problem, coordinating the team, etc. "Hey guys, we need some certificate management" is answered by "great, we'll expect you to get that implemented in the next release." Many people would rather keep their head down than assign themselves extra thankless work.

Re:Anyone wondering why?

[Opportunist]

Bluntly, if I get ZERO problem reports from your department, it's time to close it. NO problems means that you're not working, and if you're not working I can do without you.

This is why the CISO should not be sitting below the CIO in the hierarchy structure. Personally, I'd of course prefer to sit comfortably directly under the CEO, but that's wishful thinking in any company where ITSEC isn't a key asset, like in R&D heavy companies or companies that deal with ITSEC themselves. But it's also fine to sit underneath the CSO (and it doesn't even matter if that S is security or strategy), even the CFO works. But you can NOT put the security office beneath the office it should secure. This can only work with a very security conscious office head, and we all know how likely that is. Reporting to the person whose security is in your hands might seem like a sensible thing, but in general it means that all your security reports go there to die. At the very least such a report has to filter upwards as well so HIS superior will want to see how he dealt with the security issue. I have no problem with the CxO getting his CSxO's reports ahead of upper management (to give him time to react and fix things so they need not go further up, upper management doesn't really like to deal with security crap and they are very quick to simply throw it away if it comes too often), but ONLY reporting to him is asking for trouble. It's akin to finding a security bug in $company's software and not being able to report it to anyone but $company. Take a wild guess how that ends.

As stated before, and to stress and explain it, I would NOT recommend a fast path to (vice) director level for security issue reporting. These people do not tend to understand the implications without explanation, and they don't like to be lectured and shown that they don't know something their underlings do know. You have to use this tool very selectively and carefully or it dulls very quickly. If you hand up 2 sec reports a week, and they find out that 9 out of 10 thereof are actually taken care of by the relevant departments before they have a chance to even understand what's going on, you're quickly seen as a boy crying wolf. And you know how that story ended.

A report to the top level should be reserved to those moments when the responsible departments are either unable or unwilling to deal with the problem and when you need more "muscle" to get it done. It should be reserved to those problems that you actually deem mission critical, because you will ruffle quite a few feathers with it. Face it, you're not making friends in a company by kicking in doors and using a (vice) president to get your way. And as security you are dependent on the people around you, they're your best and least expensive security sensors. I usually got more security related input from staff than from any technical "surveillance" means installed. If people trust you, they are invaluable.

You can even make friends with sales if you hand them security topics as selling points. Give them ammo to shoot at clients with, and they'll be more willing to hand you information about security problems even if that delays their delivery, but they have something they can tell the client so he doesn't jump ship. Of course it highly depends on your product (but if security is a non-issue for the customer, it usually doesn't delay shipping), but if your customers are at least somehow security conscious (and they sure were those 2-3 years ago with Anonymous hacking the planet and then some) they will accept another week to get a "superior" product.

And whatever you do, never ever get on the bad side of PR. They're your last line of defense when things go south. If PR wants you gone, the first minor incident is your death spell, they can easily convince management with a single press release that they can shift all the blame on you and hang you out for the scavengers to pick on.

Re:Anyone wondering why?

[Opportunist]

And this is why I made it a rule that whoever reports and issue won't have to fix it (unless they really want to). It sure increases motivation to report things, especially if you work in a small department where it is likely that you get the job if someone else reports it. I've had times when people were dashing to my office trying to be the first to report something.

As you see there are strategies against any such problems, the problem is that management often doesn't think that far ahead. You could get a lot more done if you took the human factor into account, if you used human nature in your favor instead of trying to find strategies how to cope with it. Yes, at times it makes you seem like an asshole, but face it: You're management. 9 out of 10 people in the company ALREADY see you as an asshole.

As for the first problem, for that you need a good and convincing CISO. A CISO who actually wants to implement security and not just write a bunch of CYA papers so he doesn't get fired when (not if) the shit hits the fan. Yes, such people are rare and they're usually more expensive than the CYA writers, but, dear management, you DO WANT those people. The CYA paper writer is useless to you. Yes, he is cheap, but he does NOT provide security. He provides job security for himself, nothing else. Unless you have a very good reason to have a CISO as some sort of figure head that keeps a chair from going cold or flying away, you're better off if you fire him and leave the place vacant. You get the same level of security, but even cheaper than that twit because you save the money for his wage.

A "real" CISO is more expensive. No doubt. Not because the person is more expensive (surprisingly, the "good" ones are actually often less expensive to hire), but he will need a much higher budget because he will actually have to DO something, and he will increase the cost in other departments because they will have to follow his security recommendations. Again, there's a fine line between "sensible security" and "building himself a monument".

Passive Aggressive

[Anonymous Coward]

Many people working in IT dislike confrontations. They just want to get on with what they know they need to do.

They will make an effort to communicate security risks, but if they are rebuffed and they have sufficiently covered their ass ... then they will be tempted to follow the instructions of their superiors to the letter (ignore whatever they were told to ignore).

Which means sitting back and watching the fireworks. Passive Aggressive - an unfortunate but accurate description of me and many like me.

Re:Passive Aggressive

[Anonymous Coward]

I've seen a guy (not IT, but a UAW worker) get nailed for malicious compliance after destroying something. Everyone within earshot turned to watch the operator perform the instructions given by the manager, because everyone knew it was going to result in fireworks.

You know what happens to non-union guys like us? We don't get a malicious compliance write-up, we just get fired.

For a lot of us, if we give up and move on, it fucks over the company more than any willful act could - we are the only ones who know how to keep certain things running.

Re:You talk about it, then they have to do somethi

[Opportunist]

If upper management is worth a dime they'll play that ball back into your field and ask you what's to be done.

That's basically what I do when IT comes with a problem I don't instantly understand. What is the problem? What is the implication? What can be done against it? What can you do about it? What can I do to give you what you need to do it?

Adversarial

[endus]

Adversarial is the key word here. Business doesn't view security as an entity trying to protect them from liability, get them on par with industry norms, and maybe even create some efficiency and ease support burdens, they view security as an impediment to signing the contract. Your own security team is just trying to save you from yourself...arguing with them as a proxy for the customer doesn't get you anywhere but into even more trouble.

Re:almost all said "too technical". Wrong words, t

[whoever57]

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".

A smart boss would ask you to explain the significance of the "too technical" stuff that you are trying to explain. If the boss doesn't understand still doesn't ask why you think something is important then he is just as much to blame for the communication failure.

So I must be blessed

[rickb928]

Around here, security rules. Adds and changes to apps go through security review, separate standards are published and enforced, and all this lives inside a secured perimeter that is well monitored and regularly improved.

My own workstation refuses most removable media, and if I can get one attached, my senior and not-so-senior managers get email alerts that this was done. Yes, this impacts an old app that expects to save to a floppy, even the SUBST command trips this alert. Flash drives etc don't work any more.

Besides full disk encryption and the usual passwords and signons, only one of my current passwords lives for more than 15 days.

I regularly do battle with app teams to accommodate our users needs to enter valid and accurate data despite restrictions on characters etc. Since SQL injection attacks still succeed, they need to jump through the hoops to sanitize data. And they do, with much grumbling. They would rather point to security and refuse us, but people do have apostrophes in their names occasionally, for instance.

Before this, I did work with small businesses. They are sensitive to cost, and it seems there is just no way to be well-secured without spending a lot. I left that business just as SAAS started to gain traction. We call that the Cloud now. I'm glad I don't do Cloud. It was bad enough when I screwed up, but to explain it wasn't me? The boss wasn't interested, I was responsible, even if I didn't approve of the provider. But that's par for small business, and a lot of mid-sized also.

Security is just impossible now, a losing game if you can't sign on with a massive provider or hire yourself a few PhDs.

Re:So I must be blessed

[HiThere]

I'm not really convinced that it's good practice to change passwords frequently. They need to be long, unpredictable, and memorable. That makes good ones hard to come by. If they aren't memorable, they'll just be written down. In fact they'll NEED to be written down if you change them very often.

Re: So I must be blessed

[Anonymous Coward]

I use hints. Not one of my passwords are written anywhere. But in

Choose your poison

[tutufan]

In the bureaucratic world, I've only seen two kinds of security: nonsensical and nonexistent. On the whole, I prefer the latter.

We have Insurance for that

[Anonymous Coward]

That is the answer I get when discussing any risk management or business recovery issues with management. When I ask to review the policies I am told its taken care of. I know for a fact that some items on typical insurance policies like say backup and recovery are not implemented or tested (it cost to much).

Until there is a set of guidelines for small/medium business I fear no change will take place.

I communicate to my immediate manager/supervisor

[Anonymous Coward]

I report security issues to my immediate manager/supervisor and make note of when and what I did in my journal. After that its no longer my problem.

Serious Issues = Personal Complaints

[Anonymous Coward]

It's amazing how many companies actually do this. Even had a company once ask why I was the only one having a problem, (they wanted us to do a tour that took an hour and a half, every hour). Everyone else was just faking the paperwork, which is what I went back to.

geeks don't tak to business

[Anonymous Coward]

I will also add that I never go directly to the executives or even business/product management, I follow the process, which means Manager and BA since its their job to communicate with the business/executives, not mine.

Now if an executive asks me a question, I will answer straight up to the best of my ability, but I never go to them.

IT would be easy

[houghi]

if it wasn't for the other people.

Tough luck. You are not your own company. Sure, there are good managers and there are bad ones. Just like there are good IT people and bad ones.

Many IT departments I have been in contact with don't listen "Please follow procedure." without any reasoning. 10 different logins that they choose with different password rules for each of them. Next they moan if I call for a reset.
I have seen how they did a annual presentation of their department with a one page excel sheet. I have seen an IT department tell everybody to leave the building and go home, because there was a computer virus. Inadequate people are everywhere, including in IT.

I have seen bad management teams as well. Looking for whatever they were looking for and not listening to reason. IT department who told they could save a LOT of money, but no reaction what so ever. Investing 60 EUR was prohibited, because nobody cleared it and thus at least 120EUR per day was lost. Meetings of several hours of the brand of coffee that would be bought for 50 people.

So unfortunately it comes all down to interacting with others. If there is a dialogue possible, it all went well. If no dialogue was possible, it all went to shits.

Two way street

[Anonymous Coward]

Ya, right, it's the communication fault of the technical people, bullshit. That's the canned excuse Business people use. In order to preserve that excuse they have no desire to understand.

what does blame buy you?

[raymorris]

> If the boss doesn't understand still doesn't ask why you think something is important then
> he is just as much to blame for the communication failure

That's true for ANY communication failure. What does blame get you?

If I'd like to get something done, I can either communicate it in a way that gets it done, or not.
It does me no good to go about it such that it fails and I can blame the other guy.
Blame and $2 will buy a cup of coffee ($8 in California).

The Ding Culture

[Anonymous Coward]

It is the "Ding Culture", nobody wants to get "dinged".

I started off my career with the ethic of being completely honest about what I could do and could not do. If I found a flaw or mistake in my code, or someone else's I would report under the belief it would prevent problems and be welcomed.

Then I had a job where if I mentioned a problem, even before it occurred, I would "get dinged".

So I learned to keep my mouth shut and fix things on the sly.

You can't expect to have open communication if you penalize people for what they might say.

And when you do let them know...

[ImOuttaHere]

I warned company execs to exactly these kinds of risks. I angered the president of the company to the point that I was laid-off as soon as he had the paperwork processed. I was surprised he didn't fire me on the spot. That's how badly he demanded that engineering and manufacturing be moved to China. He refused to hear of any risk to company intellectual property. He knew the value of his stock options depended on doing what he, in the end, did.

I got "turfed" for all my hard work. This, after I spent 30 years in the industry and provided product development engineering talent and software technologies that contributed directly to much more than 100's of millions of dollars on their bottom line each year.

Is there really any question why people won't communicate these kinds of things "up stream?"

Re:almost all said "too technical". Wrong words, t

[Kielistic]

Should it not be management's job to know that security vulnerabilities lead to business problems? Why is it IT's responsibility to learn business management, legal requirements, etc?

If I go to management and say "the fire escape is broken" it is their responsibility to deal with it and understand the consequences (that is what they're paid the big bucks for after-all). I don't have to go through case law, reports and news story and provide them with a powerpoint documenting that company X got fined 50 trillion dollars for having a broken fire escape and we have an P% probability of having the same happen.

Re:almost all said "too technical". Wrong words, t

[Spudley]

Maybe point to a line in the WSJ article that says...

Yes, but that would require the techie to understand the management speak in the article.

There's the problem again.

based on professional knowledge or desired outco

[raymorris]

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.
 

We logged over 10,000 attacks last month. Data.

[raymorris]

I don't know about you, but I HAVE hard data to base my estimates on. If you don't, a professional opinion giving a rough estimate isn't "made of whole cloth". If you're making recommendations, you should be able to say with some confidence that an SQL injection attack on a public web server is at least 100X more LIKELY than having your WAP cracked. Management may not know that, but somebody in IT should know it and be able to communicate it to management.

Yeah, I did that once...

[CitizenCain]

Last time I communicated security risks to an executive, I was told to shut up. The owner/CEO had been using "bob" as his password for 30 years and wasn't about to change it, or allow password complexity policies because of some "theoretical risk." ...if only I'd thought ahead and gotten his E-trade username before I quit...

management isn't reading this thread

[raymorris]

Perhaps they should do this and that. They aren't reading this thread, so talking about what they should do is not helpful.
What can we nerds do to help the situation? If speaking in terms of business risks solves the problem ...

You see relevant news stories on CNN / MSNBC / Fox. How hard is it, really, to send your boss the link with a note saying "I noticed we're vulnerable to this. I'd like to discuss securing our systems from this type of problem"?

Re:management isn't reading this thread

[Kielistic]

You see relevant news stories on CNN / MSNBC / Fox.

Not necessarily (I certainly don't anyway). How many news articles do people see in reality? Especially ones with enough technical detail that an IT admin could say "we're vulnerable to that exact situation".

Talking in business risks isn't really an IT person's job nor is it their expertise (so they wouldn't be able to do it well). If management is already ignoring their senior IT staff then if IT came and tried to sound "businessy" management is likely to pat them on the head and reply with "you let me worry about the business".

Talk to the hand

[Anonymous Coward]

It's too much information. I don't care how it works. Just fix it.

Don't ask, don't tell.

[DarthVain]

It isn't that management doesn't care, or doesn't understand (which probably happens a lot anyway), it is the fact that the things they DO care about and DO understand are all negatively effected by "Security" issues.

Basically application development becomes more complex, expensive, cumbersome, requires more approvals, documentation, oversight, etc...

All things that a manager doesn't like to hear all summed up in a word. Combine this with FOI and privacy, well he is in for a bad day.

Oh and it has to be hosted on a more expensive server that is harder to get to, and is inconvenient for all your clients, and other applications to talk to, requires additional regular IT support you are required to pay monthly, etc....

So yeah, when you work for a boss that "doesn't want to hear it", likely he only does when he absolutely has to (and some might have subjective degrees of when that is).

Other departments don't either

[aaronb1138]

The finance department doesn't communicate when they have taken risks that might cost people their jobs or the company entirely.

HR doesn't let you know how much you should be paid to be paid fairly or what benefits you should get much less what other people get.

Accounting doesn't tell you when the company gets behind on payables and vital services are about to be cut off.

Marketing doesn't tell you when they've botched everything and blown the company cash reserves on a hack job SEO contractor and sales database.

Management doesn't warn you before layoffs.

Security guards don't tell the rest of the company when their cameras are broken.

The cafeteria doesn't tell you when they might have undercooked the chicken.

Seriously, somebody missed the point of specialization. Yes, more communication would be better, and that is why we have so many middle managers. Unfortunately, that field of specialists are the leftovers and weakest at their jobs. Good thing they aren't actually critical, but downsizing them out has always proven difficult. The point of a department is to take care of a given scope of operations and to take the burden of worrying about such things off the other employees.

Re:Other departments don't either

[Anonymous Coward]

Finance, HR, Accounting, Marketing, Management and Security are viewed as 'part of the business'.

IT is viewed as 'not part of the business'.

This means that IT gets no budget, no respect and no input. Nevermind that the business comes crashing down if the systems grind to a halt. We're here to make sure Tim McManager can look at his personal email at work on his iDevice.

Re:almost all said "too technical". Wrong words, t

[Anonymous Coward]

But don't you see the problem there? Your boss doesn't listen to you. Your boss listens to WSJ and Forbes. Why?

And saying that "the boss speaks business, the tech speaks geek" doesn't quite get to the heart of it either. If the parties valued the communication, they would talk it out and reach an understanding. I suspect that the parties (either or both) don't care enough to reach that understanding.

Look, we have to be real here. I've been in IT 25 years and during that whole time I've been reading about one technical risk or another. There have been thousands over the years and security is the job that never ends. If I notified management of every issue they'd think I was the Boy Who Cried Wolf.

The next issue is, for the techs, it's not at all easy to measure what the actual risk of any given exposure is. Most of us aren't security specialists and even for those who are, measuring the risk exposure is a mug's game. Even ranking them is tough. That's one reason why I liked the SANS Top 10 list.

From the business side, the security message is a bad news story. Either the company spends money to prevent/control/mitigate the risk, or it accepts the risk of the exploit. Simply knowing about the risk imposes liability upon management. It's bad news all around. We can decry adolescent behaviour on the part of management but in strictly human terms, it understandable that they might want to simply run away and stick their head in the sofa. If the boss is an A-Hole, then this correlates to blaming the messenger.

IT Staff doesn't understand security risk

[mysidia]

The article's talking about IT staff not communicating security risks. But my argument would be Most IT staff do not have sufficient understanding security risks.

They may understand that certain bad things can happen.... but do they actually know how likely they are? NO.

IT staff can give you some idea of what some of the risks are, but only from a limited perspective.

To have a full understanding of risks, you need more than a technologist's point of view.

You need both the technologist's understanding of the risks, AND an understanding of the statistics and research in the field of security. Security risks should be evaluated by personnel who are equipped to do it, not by IT.

One of IT's jobs should be to confer with security personnel, and security personnel can ultimately check the research and run the internal studies to make the necessary findings about extent of risk, and help senior management come up with the appropriate strategy that balances all the various risks and mitigation costs.

Who needs to adapt?

[manu0601]

From TFA:

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

Here is another possible outcome: change the executive and get people that actually able to understand what is going on in their company, and what their employees are doing.

true, I skipped step 1, that is step 1

[raymorris]

True, I skipped step 1 "get a few levels above helldesk".
However, if you can speak business, or translate a little bit of techspeak into something that makes business sense and do it in front of a mid-manager or above, that may help you GET into a position where you can do so regularly.

Heywood...

[Anonymous Coward]

jablowme?

Why bother?

[Anonymous Coward]

If you report all security risks to management, they will rebuff your assertions with half-truths, and things they misunderstood, or simply made up. They will also treat you like a raving loon. Most actually have to see damage done, and even in the face of a current ongoing external security breach, most would somehow make up some kind of story to blame the IT person for it. I have no doubts for example that when TJ Maxx installed WEP on their WIFI routers, someone alerted them, but was told to 'keep pushing your wire into things, and leave business configuration to people who wear ties'. Later they lost billions, and caused immense security and monetary headaches for dozens of banks, but refused to accept any blame themselves. But getting back to the general discussion: why speak to them if they won't listen? You can't get away with "I told you so" after damage has been done, because they will claim 'they didn't (and still don't) understand all of this computer gibberish'.

Adversarial

[Dabido]

Everywhere I've worked (as a sys admin or network engineer) we've always voiced our concerns and it is always the 'adversarial' problem. Management has a problem with the 'security through obscurity' thing, where they think no one outside the company knows the companies network exists. You can talk till you're blue in the face, but they won't listen. They even make statements about the firewalls just wasting the companies money. Last place I worked they insisted that 'password' was a good enough password for people to have, and removed a rule that didn't allow it. The main people who pushed it were the IT manager and the infrastructure team leader (who was an MS Server Admin - you'd think they'd know better). There were some other stupid decisions I won't go into, but whenever a new manager comes in and starts to pull apart/destroy the security of the network, it is always a good time to leave.