9

I have worked for a number of organizations in the past that utilize practices that are justified by what I would describe as "Security through Obscurity" including the following:

  • Weak/Vulnerable two way hashing of passwords
  • Utilizing various API's/Utilities know to all to contain serious vulnerabilities
  • Various forms of data/code obfuscation
  • Sloppy/No user management
  • The continued use of incredibly insecure passwords
  • (The list goes on and on...)

Often times the fixes to these issues do not involve a large investment/change and I find it easy to get resources aligned to resolve them. My issue is in justifying any potential fixes, when these practices are challenged typically the concerns are dismissed with comments such as:

  • "only group xyz has access to that network/product/machine/login/whatever"
  • "that isn't a big concern" - The unstated version of:
  • "no one could guess that/know to test that"

Even when in environments where security is very taken seriously, and audits are an ongoing concern, I have always found it challenging to convince others(especially non-technical/managerial types) of the importance of designing and maintaining systems that are secure by design.

I've found that when you use an example people will agree with you on principal, but the lesson really never sinks in. When confronted with an thorough explanation of why a particular system/subsystem is vulnerable management will often fall back on "it's not a priority right now"(I can't defend it and I don't care) argument, valid in it's own right, but more times than not rather than identifying and logging the issue, reflecting on lessons learned, and establishing a schedule to meet a certain pre-definded level of compliance, management often times discards any evidence contrary to full compliance, ensures all related parties that the previously mentioned system is "secure", and ships the product.

I am of the opinion that security through obscurity is not an effective part of a secure system and that resources spent of such schema's are resources better used for other parts of the application.

I've found over my career that the most difficult part of implementing a secure system is not convincing others of the value of a secure system or in gathering the requisite resources, but in convincing others of this principal. Efforts expended to improve an organizations security often turn into one man crusades rather than systematic and long term changes in culture and practice.

At the risk of being to broad or generally opinion based, what are the best strategies for teaching others the value and reasoning behind avoiding "Security through Obscurity"?

David Rogers
  • 191
  • 3
  • 4
    Call me a cynic but I often think it suits people to not understand. If the cost to fix something is coming out of a manager's budget, their motivation is to make you go away without them appearing publicly negligent. This is made worse by many security consultants making greatly excessive recommendations. Some organisations have had success changing the organisational structure to address this. – paj28 Dec 12 '17 at 07:23

1 Answers1

6

In this situation, you are likely going to need management to set standards and force change. But you have to communicate to management in a particular way.

Step 1: do a risk assessment. Although a certain issue might not be best practice, is the cost of the change going to save the company any money or reduce risk to a point under the risk threshold? This is something that can help get management (potentially) on board.

Step 2: show how other teams or companies have avoided problems, gained customer confidence, or seen success by doing things differently. Showing where other companies had problems will not work.

Step 3: start with small changes by getting an ally (person or team) to go through the change process as a "pilot" with strong and visible management support. Support them in whatever way they need to be successful. Document the challenges and successes and broadcast them to the rest of the teams.

Step 4: measure and document the benefits of the change, both in terms of the benefits to the development teams and to management and the company as a whole (if possible).

Step 5: ask for a volunteer team to try out the new approach on another small-ish but bigger pilot. Repeat steps 3 - 5.

The 2 big things you need to be able to track is the benefit to management to keep doing this (in terms that they understand), and the benefits to the development teams to want to do this (in terms that they understand).

It's easy to get a culture to change if everyone is benefitting. It can be very difficult to show those benefits in real terms, but well worth the effort. I've seen massive change in teams and companies in a short time using this type of approach.

schroeder
  • 129,372
  • 55
  • 299
  • 340
  • I found out budget is more often than not the biggest driver to do something. Management will probably ask "what is the price?" In my (short) experience, my cost calculations prove very usefull, as well as comparing different options. Yes, that takes time, but I think it is worth it. If possible, ROI, reduced risk figures (lower impact or chance to occur/occurrance) always are very useful tools. If done correctly of course. – johan vd Pluijm Dec 12 '17 at 11:57
  • @johanvdPluijm price is not a motivator - cost/benefit should be the motivator, which is what I am talking about. Show that the price or the effort (both are forms of 'cost') results in a value that is greater than the cost. That's how you get buy-in. If I sell you something that costs $50,000, but it will give you $100,000 in benefit in a year, then does it matter what it costs? Would you not borrow to your limit to pay that price? – schroeder Dec 12 '17 at 12:38
  • thats what I meant with the ROI etc. But if there simply is no budget (my experience...), it will become very hard to convince people to do an investment. Especially when that 100k takes a lot of time to get back and the 50k has to be paid before the end of this year, for example. – johan vd Pluijm Dec 12 '17 at 13:15
  • 2
    If the company has the attitude of "we haven't been compromised,so we're in good shape", it's a lot tougher to sell management on the need to change. I've run into that with teams at my current employer: "all that control you want just slows us down and gets in the way. We haven't had a virus in a long time, so please leave us alone." It's an uphill battle and we need to fight it through upper management. – baldPrussian Dec 12 '17 at 13:54
  • 1
    @baldPrussion that's known as Near-Miss Bias and there are strategies to communicate into that – schroeder Dec 12 '17 at 17:07
  • Hmm, yes allot of that I already do, but the details of communicating the benefit is sometimes a little challenging, right now I break risks down by likelihood and potential damage, assign each a score(in effect) and then communicate along the lines of: We mitigated one "Severe" risk, and one "Moderate" risk by doing XYZ. This works well with higher ups, but when you get people who ask probing questions like why XYZ("I don't get it") is where I run into issues, either they need to trust me completely or comprehend the concept, both of these can be really hard to achieve. – David Rogers Dec 13 '17 at 21:18
  • you are correct - that's why it has to be in terms that they understand - you need to translate the risks into terms that make sense to them - it is not straightforward but worth the effort to figure it out – schroeder Dec 13 '17 at 21:19