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.

Application Security

1/8/2018
10:30 AM
Mike Convertino
Mike Convertino
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Vulnerability Management: The Most Important Security Issue the CISO Doesn't Own

Information security and IT need to team up to make patch management more efficient and effective. Here's how and why.

This piece was co-written with Amber Record, a security engineer at F5 Networks. In her role, Amber is responsible for leading the company's vulnerability management program.

The number of attacks like the recent one against Equifax have risen dramatically in the last few years, resulting in the exposure of hundreds of millions of private records. Almost without exception there has been some fundamental flaw related to configuration or patching of systems. This trend will continue without systems designed to automatically identify, patch, and close vulnerabilities in core IT systems that can reduce the chance of human error.  We can accomplish this with automation typically found in large operational cloud deployments and the Constant Delivery (CD)/Constant Integration (CI) principles of DevOps.  These principles are already being used to automatically stop active attacks within the information security community and should now extend to IT operations to improve protections and stop the bad guys from getting in at all.

Where do organizations start when they realize that a standardized, managed vulnerability management program does not exist? There are almost too many options. For one, you could create your own vulnerability scanning solution. If you walk into a security team that has more than one solution, you could review them both and select the best option for your needs.  Another way is to establish a program by hiring a consultant to assist in reviewing the existing program or build one for you. No matter which option you choose, experienced contractors can easily provide a very generalized plan and you can then tune it to your company's specific needs. In the end the goal is to achieve a safer environment for your data and applications. Evaluation criteria must include manageability, accuracy, interpretability, and the ability to identify specific actions that server owners can perform.  

Once you've selected an approach, then what? The next step in the process is getting a peer review of your solution and what it might be lacking. Coordinating the plan outside of the organization is necessary to getting the program into a fully functioning state complete with ticketing to remediate vulnerabilities. The primary preference to reduce vulnerabilities is to implement as much automated patching as possible. This has two net effects: it provides protection earlier and reduces the load on application owners to manually patch systems.

Once you implement the technical scanning solution and ticketing support, the process becomes much more simplified. The primary drive to decide what to scan first should be based on risk.  One of the biggest problems with vulnerability management programs is the application owner's fear that scanning will negatively affect their applications. The information security team can throttle scans, target certain times of the day for lower application traffic, and scan applications prior to implementation in production to catch vulnerabilities sooner and reduce application loads.

The sad truth is that vulnerability management programs have either no or extremely limited ability to actively correct the flaws that they find. Most generate tickets that task system maintainers to patch systems or correct improperly configured systems. There are a few systems that either inject code into connection streams or provide generic intrusion prevention signatures that cover up underlying flaws in Internet-facing services, but to limited effect. Looking at the problem from the standard ITIL lens of people, process, and technology, we offer a new approach:

Today, most enterprises still rely on people in IT to manually patch operational IT systems, especially e-commerce and other customer-facing systems. But that's the problem — even when completely accurate vulnerability scans are delivered, there aren't enough people to patch or correct the systems in a timeframe that is relevant to prevent attack. It's a black hole for head count to continue along this sort of path, driving total cost of ownership up with limited return because, to be truly effective, nearly all patches and fixes need to be made without exception.  Instead, IT departments should hire developers that can automate the correction of infrastructure flaws as needed. Changing the makeup of the IT Ops department may create upheaval among workers who are worried about their jobs, but this isn't insurmountable if retraining is offered and embraced.

Switching to automation to address the vulnerability management problem doesn't just require different skills, it requires entirely new processes. Processes designed strictly for manual work in user interfaces won't do the trick. New processes that leverage automation tools are needed to cut out waste and "wait states" that consume time without yielding benefit. Proper testing of the operational impacts of patching and system configuration changes should be integrated with existing DevOps processes in the enterprise to prevent outages. Engineering integration skills to interconnect products like vulnerability scanners and infrastructure management systems are needed for success. The automation created should also provide metrics on the state of the systems under management to ensure that a secure state is truly being achieved.

Finally, new automation technologies will be required to complete a full cycle of vulnerability detection that automatically corrects and verifies that the fixes have been made. Orchestration tools like Puppet and Chef should be integrated with the APIs built into vulnerability scanners and infrastructure management and patching systems to make this vision a reality. It will be challenging for enterprises to accept this level of automation and "trust the machine," but it's a far better option than today's automated intrusion prevention technologies, which can result in false positives that block legitimate traffic and possibly interfere with revenue-generating business systems. 

Related Content:

 

Mike Convertino is the chief security officer at Arceo.ai, a leading data analytics company using AI to dynamically assess risk for the cyber insurance industry. He is an experienced executive, leading both information security and product development at multiple leading ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Dimitri Chichlo
50%
50%
Dimitri Chichlo,
User Rank: Apprentice
1/19/2018 | 5:09:55 AM
Automation: yes, but...
I do not fully agree with automatic patching. You never know the side effects of applying a patch. My approach is that you should first deploy on a few workstations or on a test server for critical applications, then test, then deploy full-scale. Otherwise the impact on availability of systems can be dramatic.

One of the issues faced by infra is that some patches are often marked as missing, although a newer one is superseding. This creates headaches.

And risk-based approach is also key. Do you need to patch everything? 

Some systems do not need to be patched every month, like MS servers. You can check for new patches every quarter or every six months. Is there a need for automation then? 
MichaelM17101
50%
50%
MichaelM17101,
User Rank: Strategist
1/9/2018 | 8:57:24 AM
Scanning not only option
It is important to add that, it is not needed to scan to detect a vulnerability. Too many orgs rely on scanning as the primary method. Use scanning to know your asset, match up against a Vulnerability Intelligence Feed, and then drive your VM based on risk. You don't need to patch all vulns at once, but you do need to know about all the vulns that impact your asset so you can make a risk based decision.
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Look Beyond the 'Big 5' in Cyberattacks
Robert Lemos, Contributing Writer,  11/25/2020
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: We are really excited about our new two tone authentication system!
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
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-4126
PUBLISHED: 2020-12-01
HCL iNotes is susceptible to a sensitive cookie exposure vulnerability. This can allow an unauthenticated remote attacker to capture the cookie by intercepting its transmission within an http session. Fixes are available in HCL Domino and iNotes versions 10.0.1 FP6 and 11.0.1 FP2 and later.
CVE-2020-4129
PUBLISHED: 2020-12-01
HCL Domino is susceptible to a lockout policy bypass vulnerability in the LDAP service. An unauthenticated attacker could use this vulnerability to mount a brute force attack against the LDAP service. Fixes are available in HCL Domino versions 9.0.1 FP10 IF6, 10.0.1 FP6 and 11.0.1 FP1 and later.
CVE-2020-9115
PUBLISHED: 2020-12-01
ManageOne versions 6.5.1.1.B010, 6.5.1.1.B020, 6.5.1.1.B030, 6.5.1.1.B040, ,6.5.1.1.B050, 8.0.0 and 8.0.1 have a command injection vulnerability. An attacker with high privileges may exploit this vulnerability through some operations on the plug-in component. Due to insufficient input validation of ...
CVE-2020-9116
PUBLISHED: 2020-12-01
Huawei FusionCompute versions 6.5.1 and 8.0.0 have a command injection vulnerability. An authenticated, remote attacker can craft specific request to exploit this vulnerability. Due to insufficient verification, this could be exploited to cause the attackers to obtain higher privilege.
CVE-2020-14193
PUBLISHED: 2020-11-30
Affected versions of Automation for Jira - Server allowed remote attackers to read and render files as mustache templates in files inside the WEB-INF/classes & <jira-installation>/jira/bin directories via a template injection vulnerability in Jira smart values using mustache partials. The ...