Udostępnij za pośrednictwem

Security Approaches That Don't Work

  • Artykuł

If it’s not broken, then don’t fix it ...

The problem is, you may have an approach that isn’t working, or it’s not as efficient as it could be, but you may not even know it.  Let’s take a quick look at some broken approaches and get to the bottom of why they fail.  If you understand why they fail, you can then take a look at your own approach and see what, if anything, you need to change.  The more prevalent broken approaches include:

  • The Bolt on Approach
  • The Do It All Up Front Approach
  • The Big Bang Approach
  • The Buckshot Approach
  • The All or Nothing Approach

The Bolt on Approach
Make it work, and then make it right.  This is probably the most common approach to security that I see, and it almost always results in failure or at least inefficiency.  This approach results in a development process that ignores security until the end, usually the testing phase, and then tries to make up for mistakes made earlier in the development cycle.   This is one way of addressing security.  This is effectively the bolt on approach.  

The assumption is that you can bolt on security at the end, just enough to get the job done.  While the bolt on approach is a common practice, the prevalence of security issues you can find in Web applications that use this approach, is not a coincidence.

The real weakness in the bolt on approach is that some of the more important design decisions that impact the security of your application have a cascading impact on the rest of your application’s design. If you’ve made a poor decision early in design, later you will be faced with some unpleasant choices.  You can either cut corners, further degrading security, or you can extend the development of your application missing project deadlines.  If you make your most important security design decisions at the end, how can you be confident you’ve implemented and tested your application to meet your objectives?

The Do It All Up Front Approach
The opposite of the bolt on approach is the do it all up front approach.   In this case, you attempt to address all of your security design up front.  There are two typical failure scenarios:

  1. You get overwhelmed and frustrated and give up, or
  2. You feel like you’ve covered all your bases and then don’t touch security again until you see your first vulnerability come in on the release product.

While considering security up front is a wise choice, you can’t expect to do it all at once.  For one thing, you can’t expect to know everything up front.  More importantly, this approach is not as capable of dealing with decisions throughout the application development that affect security, as an approach that integrates security consideration throughout the life cycle.

The Big Bang Approach
This can be similar to the do it all up front approach.  The big bang approach is where you depend on a single big effort, technique or activity to produce all of your security results.   Depending on where you drop your hammer, you can certainly accomplish some security benefits, if some security effort is better than none.  However, similar to the do it all up front approach, a small set of focused activities outshines the single big bang.

The typical scenario is a shop that ignores security (or pays it less than the optimal amount of attention) until the test phase.  Then they spend a lot of time/money on a security test pass that tells them all the things that are wrong.  They then make hard decisions on what to fix vs. what to leave and try to patch an architecture that wasn’t designed properly for security in the first place.

The Buckshot Approach
The buckshot approach is where you try a bunch of security techniques on your application, hoping you somehow manage to hit the right ones.  For example, it’s common to hear, “we’re secure, we have a firewall”, or “we’re secure, we’re using SSL”.  The hallmark of this approach is that you don’t know what your target is and the effort expended is random and without clear benefit. Beware the security zealot who is quick to apply everything in their tool belt without knowing what the actual issue is they are defending against.  More security doesn’t necessarily equate to good security.  In fact, you may well be trading off usability or maintainability or performance, without improving security at all.

You can’t get the security you want without a specific target.  Firing all over the place (with good weapons even) isn’t likely to get you a specific result.  Sure you’ll kill stuff but who knows what.

The All or Nothing Approach
With the all or nothing approach, you used to do nothing to address security and now you do it all.  Over-reacting to a previous failure is one reason you might see a switch to “All”.  Another is someone truly trying to do the best they can to solve a real problem and not realizing they are biting off more than they can chew. 

While it can be a noble effort, it’s usually a path to disaster.  There are multiple factors, aside from your own experience, that impact success, including maturity of your organization and buy in from team members.  Injecting a dramatic change helps get initial momentum, but, if you take on too much at once, you may not create a lasting approach, and will eventually fall back to doing nothing.

Comments

  • Anonymous
    October 11, 2005
    Hmm, I am guessing this is on a project scale?

    Th reason I ask I use a lot of these aproaches, in writing code. A project level I define all the security how I want it to work up front and then code it in but that would be a project level. But as I am writing code usually method by method I am using different security techniques at different times.

    So for example. I am writing a method in a class that does database access. First and formost I am putting in anti sql injection code using parameterized queries etc. Then I start off all variable and so on check types, and so on check for overflow. However all my error handling might not be in so I can see errors in the method as they occur. Then I test to make sure nothing is slipping by and bombard the things with data making sure it doesn't throw any exceptions as I am trying to handle problems before they occur. Then I go in and apply any permission checking if needed to see if the user has rights. Then I go back and get the exception handling all working in case something is amiss and something I couldn't handle or think of occurs. Poor Exception handling is a risk of security as well. Then on the other side I have class side exception handling where I may need to tear down or recover the class. Like I said this is my process for a single method. And why I do not do proper exception handling right from the begining is A lot of times through running test I find errors that I am not expecting or something I forgot for proper code operation that can be obfuscated in exception handling.

    I will then also have a global exception handler to try to handle an exception that occurs. Kind of the also catch all.

  • Anonymous
    February 15, 2007
    Have you noticed that little slogan in the bottom of p&p logo? "proven practices for predictable

  • Anonymous
    May 23, 2007
    I am not marketing guy, nor strategic one – I really do not know why I started to read this post - Why