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 has nearly 30 years of experience in providing enterprise-level information security, cloud-grade information systems solutions, and advanced cyber capability development. His professional experience spans security leadership and product development at a wide ... View Full Bio
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: Apprentice
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.
Intel Says to Stop Applying Problematic Spectre, Meltdown Patch
Kelly Jackson Higgins, Executive Editor at Dark Reading,  1/22/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.