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.

Analytics

3/16/2015
06:00 PM
Connect Directly
Twitter
RSS
E-Mail

10 Ways To Measure IT Security Program Effectiveness

The right metrics can make or break a security program (or a budget meeting).
3 of 10

Mean Time To Fix Software Vulnerabilities
Whether for web, mobile, cloud-based, or internal applications, organizations that build custom software should be measuring how long it takes to remediate software vulnerabilities from the time they're identified, says John Dickson, principal at Denim Group.  
'This measurement helps organizations understand the window of vulnerability in production software,' Dickson says. 'Unfortunately, most organizations do not publish this metric internally and as a result, the most serious application vulnerabilities, like SQL injections, remain in production far too long.' 
Realistically, this number may be skewed by fixes that don't ever occur, particularly during the development process. Which is why organizations should also be tracking the number of critical defects fixed against those reported, which will show how effective static analysis is for the organization, says Caroline Wong, director of security initiatives for Cigital. 
 
'To obtain this metric, the software security group must be performing static analysis, counting the number of defects initially found -- by classification, during first scan -- and counting the number of (critical) defects which are actually fixed by developers,' Wong says. 'The quality of the code will not actually increase until the developer performs triage on the findings and fixes the actual software defects. The desired trend for this metric is to increase towards 100 percent.'  
 
(Image: Pixabay)

Mean Time To Fix Software Vulnerabilities

Whether for web, mobile, cloud-based, or internal applications, organizations that build custom software should be measuring how long it takes to remediate software vulnerabilities from the time they're identified, says John Dickson, principal at Denim Group.

"This measurement helps organizations understand the window of vulnerability in production software," Dickson says. "Unfortunately, most organizations do not publish this metric internally and as a result, the most serious application vulnerabilities, like SQL injections, remain in production far too long.

Realistically, this number may be skewed by fixes that don't ever occur, particularly during the development process. Which is why organizations should also be tracking the number of critical defects fixed against those reported, which will show how effective static analysis is for the organization, says Caroline Wong, director of security initiatives for Cigital.

"To obtain this metric, the software security group must be performing static analysis, counting the number of defects initially found -- by classification, during first scan -- and counting the number of (critical) defects which are actually fixed by developers," Wong says. "The quality of the code will not actually increase until the developer performs triage on the findings and fixes the actual software defects. The desired trend for this metric is to increase towards 100 percent."

(Image: Pixabay)

3 of 10
Comment  | 
Print  | 
Comments
Threaded  |  Newest First  |  Oldest First
RyanSepe
100%
0%
RyanSepe,
User Rank: Ninja
3/17/2015 | 8:44:18 AM
Vulnerability Assessment
Many of these ways focus around and IRT(reactive) and Vulnerability Assessment Process(both proactive and reactive). These are two reactive measures that if handled effectively can increase an organization's security posture expontentially. However, many organizations do not employ these effectively. The reasons for this vary, bandwidth, personnel, expertise, etc. This is why sometimes outsourcing to an MSSP is beneficial. This argument can be made using the statistic aggregation denoted by this article.
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
NetCAT Vulnerability Is Out of the Bag
Dark Reading Staff 9/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3738
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. A malicious remote attacker could potentially exploit this vulnerability to coerce two parties into computing the same predictable shared key.
CVE-2019-3739
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to Information Exposure Through Timing Discrepancy vulnerabilities during ECDSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover ECDSA keys.
CVE-2019-3740
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Information Exposure Through Timing Discrepancy vulnerabilities during DSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover DSA keys.
CVE-2019-3756
PUBLISHED: 2019-09-18
RSA Archer, versions prior to 6.6 P3 (6.6.0.3), contain an information disclosure vulnerability. Information relating to the backend database gets disclosed to low-privileged RSA Archer users' UI under certain error conditions.
CVE-2019-3758
PUBLISHED: 2019-09-18
RSA Archer, versions prior to 6.6 P2 (6.6.0.2), contain an improper authentication vulnerability. The vulnerability allows sysadmins to create user accounts with insufficient credentials. Unauthenticated attackers could gain unauthorized access to the system using those accounts.