Application Security

12/19/2014
10:30 AM
Kevin E. Greene
Kevin E. Greene
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Time To Rethink Patching Strategies

In 2014, the National Vulnerability Database is expected to log a record-breaking 8,000 vulnerabilities. That's 8,000 reasons to improve software quality at the outset.

As of the end of November, the National Vulnerability Database (NVD) had reported more than 7,300 vulnerabilities for 2014. That's the largest number of vulnerabilities ever reported in one calendar year -- and there are still more than a few days left in 2014. By the end of December, there is a strong likelihood that the total number of vulnerabilities will surpass 8,000.

Table 1: National Vulnerability Database CVEs

Year Matches Total
2011 4,150 4,150
2012 5,288 5,288
2013 5,186 5,186
2014 7,310 7,338*
*2014 Common Vulnerability Exposures JanNov

This record number represents 8,000 reasons to improve the overall quality of software through better development and secure coding practices from the outset. Sure, patching helps by bolting on security after the fact, but patching only can go so far. It becomes nearly impossible for organizations to patch anywhere near 100% when you take into account zero-day vulnerabilities, manual patching, ineffective patch management solutions, the inability to patch critical systems that can't be taken offline, and other factors that impact the operations of IT system environments from heterogeneous environments all the way to the emerging new world called the "Internet of Things."

If not patching, then what?
What we need is a more proactive, modern approach to protecting IT systems. Patching or patch management has become an outdated approach for securing systems. It's outdated because the software ecosystem has evolved, and patching doesn't scale well enough to address the ubiquitous and heterogeneous nature of software. The size and complexity of software also introduces the likelihood for more vulnerabilities, which causes organizations to lose control of their software and IT systems. Unfortunately, you can't patch what you can't manage or control.

Software assurance, then, becomes a key component in proactive approaches to protecting IT systems. Software assurance provides a degree of confidence that software is free from weaknesses that can be exploitable. From a software assurance perspective, secure coding and development are viable and realistic options to address the gaps that exist with patching or patch management solutions. Secure coding and development becomes our first line of defense in securing IT systems, no matter where that system resides. Secure coding and development helps reduce the attack surface and the ways in which systems can be exploited.

Pinpoint weaknesses
The focus should shift from hunting down common vulnerability exposures (CVEs) to pinpointing common weaknesses enumerations (CWEs) that could be exploitable. The emphasis here is to rely less on patching and patch management and more on secure coding and development. The long-term net effect will not only help reduce the number of vulnerabilities over a period of time, but it will also help reduce the cost of software failures by identifying and uncovering software weaknesses early in the development process. Studies have shown that, when weaknesses are found later in the lifecycle (post-release, maintenance phases), the cost significantly increases to fix, mitigate, or remediate that weakness.

It should be noted that I'm not advocating abandoning patching strategies. However, I am encouraging organizations to put a greater emphasis on developing better quality software. This will require some organizations to formalize software assurance strategies to ensure that security is addressed early and often in the software development process.

Investing in research and development will also be needed to advance the quality of software analysis tools and technologies that developers feel confident in using. Improvements in software analysis tools in area of coverage (weakness classes and programming languages), precision and soundness, and synergies with continuous integration and software lifecycle management tools will help guide developers and improve the fidelity of software analysis capabilities.

Kevin Greene is a thought leader in the area of software security assurance. He currently serves on the advisory board for New Jersey Institute of Technology (NJIT) Cybersecurity Research Center, and Bowie State University's Computer Science department. Kevin has been very ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Vinoth18
50%
50%
Vinoth18,
User Rank: Apprentice
12/26/2014 | 2:31:22 AM
Excellent Perspective of Patching
A well written article with a entirely fresh and different perspective of Patch Management , a pain point of many organizations. It is time we think of unconventional and out of the box strategies to close the gap between discovering a vulnerability and patching it up. 

In some cases internal fixing can also be recommended , instead of waiting for a fix by the Vendor themselves
KevGreene_Cyber
50%
50%
KevGreene_Cyber,
User Rank: Author
12/23/2014 | 8:35:53 AM
Re: I wonder
@Whoopty -- you and me both.  I'm encouraged though.  I know with my Software Assurance program, I'm trying to address the issues by provide technologies, capabilities, tools, and infrastructure to those who are responsible with all aspects of software development. #thereIShope   :)
KevGreene_Cyber
50%
50%
KevGreene_Cyber,
User Rank: Author
12/23/2014 | 8:33:19 AM
Re: Quality?
 @moarsauce123-- you  bring up both good and interesting points.  When a software breach hits home, meaning when our personal lives are impacted, you will start to see this mindshift... Actually, we are starting to see some signs of things shifting.. There has to be a greater emphasis on improving software quality, improving software development, and improving the tools that are used to analyze software for security and quaility issues.  They all go hand in hand.. Thanks for your response.   enjoy the holidays!!!
Whoopty
50%
50%
Whoopty,
User Rank: Ninja
12/22/2014 | 12:25:50 PM
Re: I wonder
Thanks for replying. I hope there are some major improvements in security, especially when the potential for damage is so high if someone were to begin infecting IOT devices on a large scale. That and privacy concerns are some of the reasons I just don't touch wearables yet. I'm waiting for the one that champions my privacy over everything else. 
moarsauce123
50%
50%
moarsauce123,
User Rank: Ninja
12/22/2014 | 12:11:24 PM
Quality?
This is not the first request for better quality in software with the goal of better security. Yet, when looking at all the trendy IT jobs lists and predictions for 2015 and pay rates of IT jobs and whatever else gets analyzed and listed, one profession and area is always absent: Quality Assurance!

Plenty of companies consider it more important to release features than quality. When it comes down to cutting implementing a new feature or properly testing an already implemented feature, testing will ALWAYS be cut.

Any manager can easily make the case for hiring more developers, hiring more QA or BA (those who should request secure systems in the first place!) positions is much more difficult. Top management comprehends that more developers will crank out more code with more features that sales can sell to make money with. What they often do not comprehend is that it will cost a lot to fix all the untested stuff once it is deployed. It is as if the gazillion papers, studies, and books written about testing and fixing early in the process just do not exist.

Why is that? Well, there are two reasons:

- customers value features more than quality

- companies consider dealing with breaches to be less expensive than keeping quality and security high

Demanding that software vendors make better quality software should always come with the acceptance that there will be either less features or higher prices. Anything else is just wishful thinking. As long as customers are not willing to make that sacrifice and rather keep patching the patches I do not want to hear any complaints about quality and security. If you, the customer, do not value quality and security, then why should we, the vendors, spend time and money on it? There is just no return on investment and in the end we only make software so that we can sell it for cash (or in case of FOSS sell services).

As long as even massive breaches like those at TJ Maxx, Home Depot, Sony, Staples, etc. are nothing more than headlines for a few weeks and a blip in the footnotes of the quarterly report absolutely nothing will change. With revenue in the tens of millions spending a few million on apologies, free credit monitoring, and some petty fines is nothing else than cost of doing business, like renting retail space or paying for online ads.

I don't even think that legislation such as mandatory software warranties will change much. As long as the masses of customers embrace mediocre applications and consider a text based user name / password combo 'security' any well-meant demands for better quality are pointless, if not ridiculously removed from reality.
KevGreene_Cyber
50%
50%
KevGreene_Cyber,
User Rank: Author
12/20/2014 | 10:21:52 AM
Re: Operating systems need to have built-in mechanisms
@Chris_Clay -- that would definitely help.  Access control policies, configuration management, and system hardening are all strategies that should be implemented correctly to fight against malware.  But keep in mind that there are other attack vectors as well that try to exploit poorly developed software.  Thanks for you comments 
chris_clay
50%
50%
chris_clay,
User Rank: Apprentice
12/19/2014 | 4:50:56 PM
Operating systems need to have built-in mechanisms
Windows has software restriction policies, just as GNU/Linux has SELinux.  People need to start using these technologies to help fight malware.  It's easier to shortcut or disable these security mechanisms, but admins need to take the time to learn them and use them as designed.  This will help prevent the spread of malware at the OS level.  Operating systems are better than ever, but will only help to fight malware if we use them and set them up properly.
KevGreene_Cyber
50%
50%
KevGreene_Cyber,
User Rank: Author
12/19/2014 | 2:04:02 PM
Re: Rethinking Patching Strategies
Check out Dan Geer's keynote from Blackhat. So...it's being discussed. 😄
ODA155
50%
50%
ODA155,
User Rank: Ninja
12/19/2014 | 1:58:55 PM
Re: Rethinking Patching Strategies
@KevGreene_Cyber,... I think liability or holding a commercial company responsible for "their" products would be awesome... it has been done in other industries, automobile manufacturing (GM and Cheverolet have been sued), Smith & Wesson and Bushmaster have been successfully sued for deaths cause by their products, so the only question is who would be the governing\enforcement body?

If we leave it up to those companies would it be tough enough, probably not... and think of the amount of hissy-fits that would happen every minute if the government decided to regulate software development. I believe that it would have to be something like a cross between OWASP, NIST and PCI, and it would need to be fair enough that a small gaming company would be treated as fairly as a Microsoft or Oracle.

 
aws0513
100%
0%
aws0513,
User Rank: Ninja
12/19/2014 | 1:53:16 PM
Re: I wonder
As a full stack developer turned security professional, I have to admit that much of the problem with secure coding practices is the classic "are you done yet" problem.

Many times, I would give an estimate of completion of a product, to design specs, with security and operations testing.  The management would give a blessing to the project upon those estimates.
Inevitably, a manager (or worse - marketing) person would tap me on the shoulder a third or half way through the project and ask if the timelines could be "compressed". 
In some cases, we would be half way through a project and the product manager would arbitrarily decide to push for a release of the project for a quick market win of some kind.

No matter how much I would jump up and down saying "NOOOOOOO", the decision for an earlier release would go forward with the expectation that any bugs would be resolved in a later patch release.

"Time to market" decision making has a colorful history of applying discounted attention to testing practices, including security testing.

(Disclaimer: This is assuming a development team that knows anything about secure design and coding practices.  I am certain there is a large number of developers out there that do not get proper training/education regarding secure development concepts.)
Page 1 / 2   >   >>
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...