Risk
4/11/2011
11:43 AM
Connect Directly
RSS
E-Mail
50%
50%

Application Security: Much More Than Secure Development Frameworks

If your organization is considering putting a secure application development initiative in place, you need to look beyond all of the technicalities and dig into the organizational challenges first.

If you haven't already, take the time to read Mathew J. Schwartz's piece, Secure Coding Or Bust. The column provides an interesting overview as to why secure software development is important.

It also provides a few good suggestions for a start, such as the Software Assurance Maturity Model (SAMM), the Building Security In Maturity Model (BSIMM), and Microsoft's Security Development Lifecycle.

These are all excellent, but don't include some of the most important hurdles that need to be leaped before the program can get running at speed. We will dig into three of those below. But first I'd like to draw your attention to an important technical resource, the Open Web Application Security Project, or OWASP. It's a vibrant security application development community that provides security how to guides, information on common threat vectors, attack techniques, and insight on most types of vulnerabilities that plague web applications. There's plenty to consume there. I suggest you dig in.

Now, onto the three essentials you'll need to win:

Get A Champion

Getting any application security program off the ground has as much to do with garnering executive backing than technical and application security prowess. Why? Because application security affects everything about your development program, from how much it costs to how defects are handled to developer training, and what developers are asked by the business to prioritize; it can even slow release times. Building application security into a program where it didn't exist before isn't easy.

What to do about it? Get an executive champion. Someone who is high enough up on the organization chart to provide the political air cover when things get tough. And they'll get tough especially when developers are being pressed to move an application forward to production rapidly--even when it has critical vulnerabilities that will "be dealt with later." Yes. That's when the knife fights start. Frankly, many--if not most--security teams don't have the power to slow down development times to address security concerns. They can advise, but they can't always make it so. An executive with this authority to slow development--when it's needed--is essential during certain times. And they'll help you with everything else you won't find in a security framework: such as getting the budget you need and convincing others that secure application development is in the best interest of the company.

Trust me: most executives don't get this stuff. And you'll need someone who has the power and the ability to fight your fight in the corner office.

Enlist The QA Teams

Having an executive champion for a secure application development program is also important to help change the way development functions. Now, rather than barging in on developers and declaring how everything they've coded until now has sucked and "you are about to show them how it is done right." You might want to try a different tact. That's could be to convince the organization that security defects should be treated and remedied as part of the normal Quality Assurance (QA) process. The reality is that many organizations don't treat security defects in the same way they treat software defects that affect performance and availability. However, making security defect vetting part of the normal QA process will go a long way to steer development teams on the right track than the security group acting like the new vulnerability sheriff is in town.

Fight The Urge To Do It All From The Beginning

Once you start looking for them, you are going to find more application vulnerabilities than can be possibly dealt with. Like flipping the light switch on a kitchen that was left neglected for awhile: the roaches and rats will be all over. Only when you illuminate your application security program it won't be insects and rodents you uncover, rather it will be more than a dozen of vulnerability classes such as cross-site scripting, buffer overflows, SQL injection, and username enumeration that occur over and over again in applications. There are probably too many vulnerabilities, depending on the size of your organization, in existing software to go back and fix every application. So start smart with a short list of common vulnerabilities you're finding in newly developed application. Start fixing those first. Slowly build from there by adding new vulnerabilities to the list that QA teams look for during their process.

You won't solve every software security problem with this, but it's certainly a leap in the right direction. And not as easy as downloading a secure application development framework and running with it.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4448
Published: 2014-10-22
House Arrest in Apple iOS before 8.1 relies on the hardware UID for its encryption key, which makes it easier for physically proximate attackers to obtain sensitive information from a Documents directory by obtaining this UID.

CVE-2014-4449
Published: 2014-10-22
iCloud Data Access in Apple iOS before 8.1 does not verify X.509 certificates from TLS servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

CVE-2014-4450
Published: 2014-10-22
The QuickType feature in the Keyboards subsystem in Apple iOS before 8.1 collects typing-prediction data from fields with an off autocomplete attribute, which makes it easier for attackers to discover credentials by reading credential values within unintended DOM input elements.

CVE-2012-5242
Published: 2014-10-21
Directory traversal vulnerability in functions/suggest.php in Banana Dance B.2.6 and earlier allows remote attackers to include and execute arbitrary local files via a .. (dot dot) in the name parameter in a get_template action.

CVE-2012-5243
Published: 2014-10-21
functions/suggest.php in Banana Dance B.2.6 and earlier allows remote attackers to read arbitrary database information via a crafted request.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.