To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
To answer a pretty open-ended question, let's tackle the fundamentals of developing software securely. Optimally, start at the architecture phase, with a threat model that tries to anticipate the most predictable attack vectors on the software. With that threat model, it's possible to design defenses in to address those attack vectors, then constantly check the code and test the ability to defend the private data.
Of course, that utopia tends not to exist in the real world, as most security professionals inherit an application or a software package and have to make the best of it. That's where gap analysis comes in. Basically this involves figuring out where the gaps exist in existing defenses and then putting a plan in place to address the issues.
How can that be done with existing code? There are three main ways and all are important. So to be clear right up front, the answer isn't either/or, it's to what degree all three techniques should be used:
- Automated testing -- Look at application scanners, which analyze source code and check for common errors that can create exposures; things like SQL injection, faulty input validation and cross-site scripting can be reasonably easy to pinpoint.
- Pen testing -- As good as many of the application scanners are, there is no substitute for a real person trying to figure out how an application can be exploited. In many cases, a penetration tester can find logic errors that are highly problematic yet can't be caught by scanners.
- Code reviews -- The third technique is to actually look through the code and find problems. Yes, this can be time consuming, but it's important. Again, there are things that a good code review will pinpoint that will be missed by the other methods.
So yes, a gap analysis does have a place in developing software securely, though more often when retro-fitting an existing application.
More information:
|
