Risk

1/9/2008
07:55 AM
50%
50%

Software Security Strategies

Four ways to kick off your organization's software security initiative in the New Year

The shift is on: Many leading firms are currently engaged in large-scale software security and application security initiatives. If your organization is not yet doing so, the best New Year’s resolution you can make for 2008 is to improve your software security.

One of the biggest challenges with software security is getting started. Every enterprise is different and there is no one-size-fits-all approach. At Cigital, we’ve helped advise and steer many software security initiatives over the last several years, and we've come up with four ways to get started. Depending on the way your enterprise is organized and run, one of these approaches should work for you: the top-down framework; portfolio risk; training first; and leading with a tool.

Software has become the lifeblood of industry, and software defects have likewise shifted from mere technical annoyances to real business problems with huge financial ramifications. Over the last several years, some organizations have begun to realize the magnitude of the software problem that they’ve designed and coded themselves into. They've come to this realization through a combination of penetration testing performed by “reformed” hackers, Web application security testing tools like IBM/Watchfire and HP/SPI-Dynamics, and code review.

The good news is that the badness-ometer approach illuminates how the software problem applies to your own software. So the common myth that software security bugs and flaws apply only to open source code or to code written by others and surely not to yours, is profoundly debunked when within seconds an automated tool hacks your Website.

The problem with the badness-ometer approach to security is that recognizing you have a problem does not actually solve the problem. The result: a piling-up of huge numbers of security bugs and flaws that have yet to be fixed. The dam is likely to break in 2008, so it's time to eradicate some software defects and to learn how to stop making more of them.

A top-down framework approach follows the plan laid out in Chapter 10 of my book Software Security. The idea is simple – perform a gap analysis between where you are and where you want to be from a software security perspective. Then build a plan to address the gaps. Make sure to include software security best practices for software you build, assurance activities for the software you buy, a portal for software security guidance, and an enterprise-wide training program for developers and architects. (See Want Turns to Need.)

The framework approach works well in an organization with strong centralized IT leadership that has both the power and the budget to undertake a large-scale initiative. We’ve seen this approach work nicely in global financial services firms, even when the development organization has tens of thousands of developers spread over multiple continents.

The portfolio risk method takes a more business-oriented approach to the software security problem. The idea here is to assess the entire application portfolio according to some risk criteria agreed on in advance. The results of this risk survey help determine which kinds of security controls and activities should be applied in what order to what applications. Organizations that are set up with strong but stove-piped business units often benefit from this approach. When executive management understands software risks clearly (and what to do to mitigate them), good things usually follow.

The training first approach to software security is more grounded in the technical world. This approach helps developers who love to do the right thing but just don’t know what the right thing is when it comes to security. Having trained over 6,000 developers on software security, here are some pointers from us at Cigital: Make sure that trainers are actually software people (not security people with no software experience); use examples from the enterprise code base if possible; and include lots of hands-on exercises with real tools and techniques. Training is an essential part of any software security initiative, and sometimes it makes sense as a first step.

The lead with a tool approach, meanwhile, makes sense for an organization that has already purchased and attempted to roll out a security analysis tool. In many cases, QA departments are furnished with Web application security badness-ometers. Sometimes development organizations are mandated to use static analysis tools like Fortify, Ounce, or Coverity. After the dust clears, the real work of tool adoption begins. In our experience, writing custom rules (linked to corporate guidelines) for code review tools can be a very effective way of upping static-analysis tool adoption. Likewise, security testing training geared for QA is important for engendering an attacker’s perspective among professional testers who are used to focusing their attention on features and functions.

In the end, your organization may require some combination of the four paths to software security.

— Gary McGraw is CTO of Cigital Inc. Special to Dark Reading

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Higher Education: 15 Books to Help Cybersecurity Pros Be Better
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
Worst Password Blunders of 2018 Hit Organizations East and West
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
2019 Attacker Playbook
Ericka Chickowski, Contributing Writer, Dark Reading,  12/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
[Sponsored Content] The State of Encryption and How to Improve It
[Sponsored Content] The State of Encryption and How to Improve It
Encryption and access controls are considered to be the ultimate safeguards to ensure the security and confidentiality of data, which is why they're mandated in so many compliance and regulatory standards. While the cybersecurity market boasts a wide variety of encryption technologies, many data breaches reveal that sensitive and personal data has often been left unencrypted and, therefore, vulnerable.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-20201
PUBLISHED: 2018-12-18
There is a stack-based buffer over-read in the jsfNameFromString function of jsflash.c in Espruino 2V00, leading to a denial of service or possibly unspecified other impact via a crafted js file.
CVE-2018-20194
PUBLISHED: 2018-12-18
There is a stack-based buffer underflow in the third instance of the calculate_gain function in libfaad/sbr_hfadj.c in Freeware Advanced Audio Decoder 2 (FAAD2) 2.8.8. A crafted input will lead to a denial of service or possibly unspecified other impact because limiting the additional noise energy l...
CVE-2018-20195
PUBLISHED: 2018-12-18
A NULL pointer dereference was discovered in ic_predict of libfaad/ic_predict.c in Freeware Advanced Audio Decoder 2 (FAAD2) 2.8.8. The vulnerability causes a segmentation fault and application crash, which leads to denial of service.
CVE-2018-20196
PUBLISHED: 2018-12-18
There is a stack-based buffer overflow in the third instance of the calculate_gain function in libfaad/sbr_hfadj.c in Freeware Advanced Audio Decoder 2 (FAAD2) 2.8.8. A crafted input will lead to a denial of service or possibly unspecified other impact because the S_M array is mishandled.
CVE-2018-20197
PUBLISHED: 2018-12-18
There is a stack-based buffer underflow in the third instance of the calculate_gain function in libfaad/sbr_hfadj.c in Freeware Advanced Audio Decoder 2 (FAAD2) 2.8.8. A crafted input will lead to a denial of service or possibly unspecified other impact because limiting the additional noise energy l...