Original URL: https://www.theregister.com/2008/06/23/scanning_security_controls/
Time to dismount the hamster security wheel of pain
Quit patching, build a library
Posted in Software, 23rd June 2008 05:02 GMT
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.
Establish an organization-wide standard security API
Now you're talking. Organizations that have institutionalized a standard application security control tend to have less vulnerabilities. And organizations that have standardized on a cryptographic library, and especially the ones that have wrapped that library in a standard encryption component, have significantly less problems in building and securing applications.
If you're tired of the application security scan-and-patch hamster-wheel-of-pain, then it's time establish just such a library. But what of the classic pain point of actually getting people to use the library, rather than falling back on established practices and techniques? Once you show that using this "secure" approach is the fastest and easiest way to get applications built, you'll see dramatically increased levels of interest in the library.
So how do you create your enterprise security library?
Most organizations need roughly 100 methods across all the different security controls, organized into a simple library. Every organization's library will be a little different, as they each use different platforms, systems, directories, databases and infrastructure.
While many organizations have standardized approaches for authentication, access control, and perhaps logging, most have not created common solutions for critical areas like input validation, encoding, encryption and error handling.
You may be able to search your best applications for these mechanisms and institutionalize them. The best approach is to spend some time designing the API for your organization's security needs, and then implementing the mechanisms.
Assuming your library is critical, you'll want to spend time on design reviews, code reviews, and security testing. Borrowing the "test-first" technique from agile methodologies is a great way to develop a test suite that you can use for regression testing.
Faster, shorter, simpler
Organizations that create a standard security library for developers will experience significant cost savings across the entire software development lifecycle. By simplifying application security, many activities across the lifecycle will take less time and yield better results. For example, security training will be shorter and more focused, security requirements reduced to half their former size, and security design and implementation will be easier. Security testing will become more effective and remediation much simpler.
Application security is getting more complicated every day with increasing connectivity, more mixing of code and data, more parsers, more interpreters, more assets, and more functionality available.
We have to take steps now to simplify the problem. So if you're tired of securing one application at a time, and wrestling with the same vulnerabilities again and again, establishing your organization's standard security library is one of the best things you can do.®
Jeff Williams is the founder and CEO of Aspect Security and the volunteer chair of the Open Web Application Security Project. His latest project is the Enterprise Security API, a free and open set of foundational security building blocks for developers.