Time to dismount the hamster security wheel of pain

[InfoSec News <alerts () infosecnews org>]

Forwarded from: William Knowles <erehwon (at) c4i.org>

http://www.theregister.co.uk/2008/06/23/scanning_security_controls/

By Jeff Williams
The Register
23rd June 2008

Enterprises are spending a huge amount of effort scanning for vulnerabilities
that they already know are in their applications. Here's a little secret:
there's no point in scanning if you haven't at least tried to put in a basic set
of defenses. You already know you're vulnerable.

So what kinds of defenses does the average web application need? Here's a good
way to figure it out. Take a look at the common application security
vulnerabilities and then list the security controls that developers need to
prevent those holes.

You'll end up with a list that includes authentication, session management,
access control, input validation, canonicalization, output encoding,
parameterized interfaces, encryption, hashing, random numbers, logging and error
handling.

It's not reasonable to expect developers to build a secure application without a
decent set of security controls for them to use. So how can you make them
available? Here's what you could and what you probably should do.


Build your own security controls in each application

This is a bad idea. Writing security controls is both time consuming and
extremely prone to mistakes. MITRE's CWE project lists more than 600 different
types of security mistakes you can make, and most of them are not at all
obvious. Most people recognize developers should not build their own encryption
mechanisms; the same argument applies to all the security controls.


Use security libraries directly

Another bad idea. There are plenty of libraries and frameworks out there that
provide various security functions - Log4j, Java Cryptographic Extension (JCE),
Java Authentication and Authorization Service (JAAS), Spring Security, and
dozens more. Some of them are even pretty good at what they do. But there are
several reasons why enterprise developers should not use them directly.

Most importantly, these libraries are too powerful. Most developers need just a
very limited set of security functions and don't require a complex interface.
Further, many of these libraries contain security holes themselves - such as
encoding libraries that don't canonicalize or authentication libraries that
don't use strong cryptographic functions. Many security controls use features
from other controls, and using security libraries that aren't integrated is a
problem waiting to happen.

[...]



*====================================================================*
"Frankly, I'd like to see the government get out of war altogether and
leave the whole field to private industry."         -=-  Joseph Heller
----------------------------------------------------------------------
erehwon (at) c4i.org      PGP key on request      www.c4i.org/erehwon/
*====================================================================*


_______________________________________________      
Attend Black Hat USA, August 2-7 in Las Vegas, 
the world's premier technical event for ICT security experts.
Featuring 40 hands-on training courses and 80 Briefings 
presentations with lots of new content and new tools.
Network with 4,000 delegates from 50 nations.  
Visit product displays by 30 top sponsors in 
a relaxed setting. http://www.blackhat.com