Risk
3/22/2013
01:01 PM
Connect Directly
RSS
E-Mail
50%
50%

Who Owns Application Security, Patching In Your Business?

Too many organizations lack a formal security plan, leaving applications vulnerable to exploits, warns SANS Institute.

One-third of businesses lack a formal program for tracking application security and prioritizing which vulnerabilities to patch first.

That finding comes from an application security lifecycle survey of 700 IT personnel -- half from large multinational businesses and a majority of whom work as security analysts -- conducted last year by the SANS Institute and sponsored by vulnerability management software vendor Qualys.

The SANS study found that over 25% of businesses have an application portfolio that includes fewer than 25 applications. But 22% manage more than 100 business applications, and 7% count more than 1,000. Furthermore, 28% of respondents didn't know how many applications their organization managed.

"In many cases, this is because the respondents work in large organizations that have grown over several years through mergers and acquisitions or are global companies with many subsidiaries, lacking central management of application portfolios," read a related SANS Institute report written by Jim Bird, CTO at for broker-dealer and trading platform provider BIDS Trading Technologies, and Frank Kim, principal consultant at ThinkSec and curriculum lead for application security at the SANS Institute.

[ Security software needs to focus less on data dumps, more on identifying trends. Read more at Security Tools Show Many Dots, Few Patterns. ]

Maintaining an application portfolio and formal application security program is important to help businesses prioritize which vulnerabilities in their commercial and open source software to patch first. The most effective approach may seem counterintuitive. That's because, according to research published in 2011 by vulnerability information provider Secunia, patching the most critical vulnerabilities is a better use of time than patching the most widely used applications. "Averaged over the last six years, patching the top 10 most critical programs [with vulnerabilities] remediates 71% of the total risk, while patching the top 10 most prevalent programs [in terms of overall use] remediates 31% of the risk, or 1.9 times less," according to Secunia.

Make no mistake: Attackers are gunning for known vulnerabilities in applications and plug-ins, because even after vendors release patches, many businesses remain slow on the patching uptake. Blame, perhaps, the all-too-frequent deluge of vulnerability reports, like the ones recently involving Java. "There has been a lot of time and energy spent lately on responding to matters relating to Java and the platform's security," said Robert Jeffries, a research analyst in the Security Engineering Research Team at managed security services provider Solutionary, Thursday in a blog post.

"We took a look at how many vulnerabilities were released for the platform going back to 1996. No really big surprise here," he said. "There were a lot of them. In fact, this past month -- February 2013 -- we saw a higher number of Java vulnerabilities released in a single month than in any other single month prior."

Each patch can be a source of new exploits. In some cases, attackers have reverse-engineered Java updates less than 12 hours after their release and added them to popular -- for those with a criminal bent -- crimeware toolkits, which stake their reputation on being able to exploit more PCs in one go than the competition.

And that's just Java. In the past few months, while Oracle has been releasing Java 6 and Java 7 security updates, it's also been releasing patches for other critical vulnerabilities in its products -- as have Microsoft and Adobe for Flash, Reader, Acrobat and other applications. Crimeware vendors quickly added related exploits to their wares, but some of the patches addressed zero-day vulnerabilities that were already being targeted and compromised by attackers.

Businesses can't instantly patch every system; they must prioritize. But how do application security managers determine which bugs to patch first? According to the SANS survey, respondents are currently tracking vulnerability information in a number of ways. For example, for vulnerabilities in open source and commercial software applications, "companies seem to use virtually every source they can," said by Bird and Kim in their SANS report.

"Approximately 59% get vulnerability and threat information by subscribing to threat notification services, open source distribution lists, vendor notification lists, CERTs, news and security services from external experts," they said. "Less than 10% rely primarily on tools from third-party vendors such as Palamida or Black Duck for updates on vulnerabilities and threats. A disturbing number (12%) don't have an established method to track vulnerabilities."

The ad hoc approach applies even more to applications developed in-house. Notably, Bird and Kim found that only 23% of organizations include application security in every stage of the development and lifecycle process: "In another 30% of companies, application security is considered important, but developers engage with the information security team only at certain points in the development cycle." Alarmingly, 26% of businesses assess the security of an application only at the end of the development process, which is relatively costly compared with catching bugs early in the lifecycle development process, and historically vulnerable to being overruled by "time to market" pressure exerted by other parts of the business.

What's the best way to address poor application security processes in a business? Start by ensuring that senior managers and the board of directors are involved, since the SANS study found that too many businesses lack clear oversight of their application security posture. "In the survey, ownership (responsibility) extends across different parts of many organizations, including risk/compliance (33%), software assurance (18%), software development (35%) and even to the lines of business in a small number (17%) of companies," said Bird and Kim.

"However, there is no central, consistent control of application security initiatives in most organizations," the report continued. "The CIO/CTO is identified only as an owner in 38% of companies, and accountability and ownership of application security hasn't reached the highest levels of the business -- only 8% of companies identified the CEO as owning some responsibility for application security."

Attend Interop Las Vegas May 6-10 and learn the emerging trends in information risk management and security. Use Priority Code MPIWK by March 22 to save an additional $200 off the early bird discount on All Access and Conference Passes. Join us in Las Vegas for access to 125+ workshops and conference classes, 300+ exhibiting companies, and the latest technology. Register today!

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.