What are the best reasons you've heard for not implementing security?

Question

We can devise the best technical solution to a security problem, but that solution needs to be applied by people, by a business, to an organization, and/or in spite of objections.

The barriers people have to implementing security interests me greatly because it affects me directly. I know others have asked about "how to get buy-in" and "good ways to educate" but my question is about the other side of the equation.

I want to hear the specific reasons you have heard for a user, a manager, or a company user for not wanting to implement a more secure policy/procedure/product. The more specific the better.

Maybe if we better understand the objections to what we do, we can be better at working with those we seek to serve.

Answer 1

I discovered a vulnerability in one client's infrastructure which could cause an outage plus data loss. When pressed for a 1-off cost calculation the client agreed it could cost them upwards of £1 million each time, so I proposed a remediation plan which would have cost under £100k.

They turned it down, as £1 million was below their lower risk threshold - they had bigger risks to set their teams on.

But a valid risk decision by the business is a correct answer to go back to a security team with, so this was fine.

Answer 2

By far the most common excuse I get so far is the age old "We'll get around to it, for now just get it working".

Various reasons for this mentality include:

• Urgent project: a barely-polished prototype is all they need to get operations running, the rest is perceived as 'non-revenue generating' and thus takes a back seat. The hustle and bustle of the workplace means this crucial work gets put further and further down the queue until it's simply forgotten about.
• Low funds: Similar to above, time is money and the firm may be short on cash to pay developers.
• Ignorance: It still amazes me stumbling across PHP developers that have been in the industry for years who don't know about concepts such as CSRF attacks, password salts, prepared statements and hashing algorithms beyond MD5. It's not that they're lazy, they're actually rather brilliant. They just simply don't know, and it's not until you're breached that you ever come across the need for it on your own.
• Arrogance: Most people also tend to take a "I'm just a small company, why would someone hack us?" mentality, believing they're too small to be worth a hacker's time. This perception of hackers as this 'all mighty, all knowing god of computing' leads people to believe they're far too busy hacking the likes of Sony and the White House to be bothered with Bob's Discount Car Parts. Truth is, Bob's Discount Car Parts might be a pinch to take down, might fall to automated penetration tests or even a rouge competitor (trust me, I've seen it happen with a similar business!). Behind the scenes is all sorts of tasty goodies: CC numbers, email addresses, personal information, free product orders...
• Lack of audits: Most developers (even myself!) think they're hotshots at security, but we simply can't tell until it falls. One way to mitigate this is through security audits by independent contractors, but they're expensive, time consuming, 'unnecessary'... these people know how to think like hackers, whereas your job is to think like a software developer.
• Developer Pride/Ego: Don't laugh, I've seen it happen. Some developers are just so high and mighty about themselves that they refuse to implement security because either they can simply beat them through other means ("Dude, I'll go to their house and smash them if they hack me"), or they refuse to have someone come along and potentially tell them they're any less than god's gift to the world of IT (related to 'Lack of audits' above).

Answer 3

I want to hear the specific reasons you have heard for a user, a manager, or a company user for not wanting to implement a more secure policy/procedure/product.

This is what I always get:

We've never had a problem so we don't need it.

I have a hard time providing an argument against that, as ignorant as it may be.

I guess the only thing you can do is prove that the system is vulnerable, which can be difficult. Sometimes though, they're right - the system is relatively secure and additional measures are not necessary or more importantly (to them), worth the cost of implementing. In that case, you'd have to prove that it's worth their dollar, which once again, can be difficult.

Is this the "best" reason? Maybe not, but it's certainly common.

Answer 4

Lets take the specific example of passwords. Security best practice would have us use passwords of a minimum length, contain letters, numbers, special characters etc and not be easy to guess. Further they should be unique to a particular site and changes every 30 or 90 days. Finally if the password is ever divulged or compromised that should be immediately communicated to the security officer and the password changed immediately. Oh and don't ever write your password down.

That's great advice from a security point of view, but virtually unworkable in the real world. Can you remember that many passwords? I literally have 100s of them.

Further have you ever had the situation where you were distracted or in a hurry and typed the password for site X into the login box for website Y? I bet if people were honest you would find this happens all the time. Did you immediately change the passwords on both sites?

Answer 5

The system or data may not have much value, and the cost of a breach could be low enough to justify a relative lack of security. For example, I don't always use strong passwords for web-based forums, because the site doesn't store my name or any personal information and I don't have any reputation to tarnish.

Answer 6

Most folks resist change of all types and accordingly will come up with endless logical fallacies to fight off the implementation of something new.

• that auditor/inspector/certifier is a nitpicker
• nothing has happened so far
• ask anyone, this is overblown
• …

Focusing on specific rationalizations (the focus of your question) missed the real issue – the natural tendency to avoid change. In pushing back against logical fallacies you are dealing with emotions and belief systems. Therefore, the best approach is not to attempt to reason with people presenting logical rationalizations against your proposal but rather to sell the idea on its benefits.

As with any good sales situation you should be presenting something of value to a person that needs it. So consider who directly benefits most from the new security paradigm and sell that person first. There are probably some folks not sleeping so well due to the very issue you are trying to address. Get to them and let them get to others with a proposal based on validated operational value. If you can’t sell it to the folks that are on the hook for consequences of an exploited vulnerability then the organization has spoken and it’s a no go.

Answer 7

1/ Seen as too restrictive: In web applications, security can often be perceived as restricting interoperability. This often occurs in systems where 3rd party plugins/addons are allowed to interact with content management systems ( osCommerce, Joomla and Wordpress to name a few ). With each shortcut they have paid heavily, and Joomla and Wordpress continue to pay the price.

2/ Good security can go out the window when code is stored in secure directories. For example depending on htaccess basic authentication to protect directories can cause developers to drop their standards in the realm of security. This also is the same when systems are developed to work in a local area network, there also, is a false belief that security is not as critical therefore standards can be more laxed.