Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

4/6/2011
06:41 PM
50%
50%

Schwartz On Security: Secure Coding Or Bust

Companies must embrace secure development techniques to stem the surge of attacks targeting Web application vulnerabilities.

Secure development offers a clear return on investment and safeguard against both data breaches and "brand erosion." So why aren't more companies buying in?

According to a 2010 survey conducted by consulting firm Errata, 57% of companies say they use some secure coding techniques, and 81% are at least aware they exist. But 43% of companies use no secure development techniques at all.

Please, non-practitioners, consider the downsides of poorly designed and buggy software. For starters, it gives attackers a way to break into corporate systems and steal information, and that gets expensive. Indeed, the average data breach cost for a U.S. company hit $7.2 million in 2010, according to Ponemon Institute.

Bugs in software are a hot attack vector. All it took were a couple of batches of spoofed emails -- with an attached Excel spreadsheet that included a compromised Flash file -- to knock down EMC's RSA unit, compromising some aspect of its SecurID two-factor authentication system. How much will that cleanup cost, especially with RSA reportedly having reached out to 60,000 customers?

Not every security incident or data breach can be traced to bugs in code, or poor application design, but many can. That's because attackers favor the easy way in. And if you want an easy target, just find existing vulnerabilities in Web-connected applications. Interestingly, that was the modus operandi of the Iranian hacker who compromised Comodo digital certificates for Google, Microsoft, and Mozilla, among other Web domains, by finding a DLL file that stored a username and password. Can you say "insecure by design"?

So why aren't more companies cracking down on insecure approaches to building applications? Perhaps it's a risk versus reward issue -- save time in the development process, or worry about Web application attacks that may occur someday in the future.

Perhaps it's because we're spectacularly ill-equipped when it comes to judging risk versus reward, especially for something abstract like security, according to security guru Bruce Schneier, chief security technology officer of BT. "More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk," he says.

If hackers are sharks, then Web application attackers are pigs -- and they're killing us. Accordingly, it's time for every company that creates code to ensure that secure development techniques are not just adopted, but required.

Where to start? Numerous secure development frameworks can help, including the Software Assurance Maturity Model (SAMM) and the Building Security In Maturity Model (BSIMM).

But according to the Errata study, Microsoft's Secure Development Lifecycle (SDL) is the most-adopted secure development framework. As with the other standards, it's free, pragmatic, and vendor-neutral. "We specify classes of tools that should be used at a particular point in time, but one thing we don't want to do is have rip and replace," David Ladd, security program manager lead at Microsoft, told me in an interview. "If an organization has already invested in a static code analysis tool and it works? Great, don't replace it."

But wait, what's secure development going to cost? "Companies adopting a 'secure at the source' strategy -- i.e. the integration of secure application development tools and practices into the software development -- realized a very strong, four-times return on their annual investments," said Ladd.

That ROI figure is based on a recent Aberdeen Group study, Security and the Software Development Lifecycle: Secure at the Source, which surveyed 150 organizations and found that about 20% "are currently using static source code analysis, dynamic source code analysis, secure software development tools, and software security testing tools," he said.

According to the Aberdeen study, the average cost to run a secure software program is $400,000 per year. But the study found that the cost of dealing with a single code-based security issue is $300,000. So if you avoid one security issue per year thanks to secure coding, then your security-savvy development techniques and tools nearly pay for themselves. Plus, think of all the data breaches -- not to mention the accompanying downtime and bad press -- you'll avoid.

All in all, doesn't clean code and a "secure by design" application development philosophy sound like a good investment?


Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-20001
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
CVE-2020-36317
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
CVE-2020-36318
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
CVE-2021-28875
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
CVE-2021-28876
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety r...