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.

Vulnerabilities / Threats

10:30 AM
Jeff Schilling
Jeff Schilling
Connect Directly
E-Mail vvv

A Winning Strategy: Must Patch, Should Patch, Can't Patch

The best way to have a significant impact on your company's security posture is to develop an organized effort for patching vulnerabilities.

If you could design a silver bullet to help win the fight against the cyberthreat, what would you do? My silver bullet idea is always the creation of a "magic button" that automatically patches every operating system, plug-in and application in an environment via a method that does not break our business processes, applications, databases and has no customer impact.

I am not delusional; I did say it has to be a "magic button." But if you had any doubt about the magic part, the recent Cisco 2015 Annual Security Report confirms that in both large and small environments, security teams are not able to keep up with patching. It is shocking that less than 40 percent of companies have an organized effort for patching and configuration management.

The study also states that 90 percent of companies are "confident about their security policies, processes, and procedures." These findings expose either a lack of appreciation -- at the executive level -- of how important patching is for hardening an environment against attack, or a disconnect with security operations mangers who battle day-to-day attacks. The confidence levels vary only slightly between verticals, geographies and job titles.

Threat actors are only after two percent of your network. They use the other 98 percent to exploit that two percent. When you view the challenging patching problem through this lens, it becomes obvious that not every machine or patch should be treated with an equal sense of urgency.

I have been accused of having Obsessive Compulsive Disorder, mostly by my spouse and the FireHost security team. However, when building a winning patching strategy, I believe being "Obsessive Compulsive" is a desirable disorder characteristic. The first step is to organize your environment, which is the hardest part of the process. However, the easiest population to address first in your patching strategy is the user hosts. Three specific steps to take include:

  • Categorize: Move all of your user hosts to VLANs and OUs that categorize them by machine type, OS, plug-in requirements and, if you can, by importance to the business.
  • Segment: Will user machines — that likely have older applications running on them — break if the OS is patched? These user hosts may need human intervention as well, or maybe a lag in patching. Segment them away from anything you really don't want breached.
  • Automate: Win back valuable time by automating the heck out of user-machine patching so you can focus your human intervention on servers.

Must patch
The next population to address are your servers, which are similar to the host-level problem. First, organize your server environment into bucket categories: "must patch," "should patch," and "can't patch." Understand you will almost always have high human intervention when patching any server. If you organize your server farms into segments of like OSes and applications, some of the process can be automated.

The obvious servers you should first address in your infrastructure are workloads (e.g., applications and databases) that manage regulated data, such as PCI or electronic medical records. These are easy to identify. If you feel challenged to do this, you may have a bigger problem in that you may never be compliant. The servers that manage regulated data must be the top priority for your patching efforts and must not lag.

Properly segmenting these servers from the rest of your environment, whether via strong internal ACLs or by moving them to a third party service provider who focuses on security and compliance, will result in their being at a much lower risk of being compromised from other servers that may become compromised themselves. Another benefit is that this segmented data would be out of the scope of a forensic investigation involving other compromised servers.

Other "must patch" servers center around those that manage workloads that would devastate the business if breached. Some examples of these servers include financial systems, HR workloads and development labs where critical intellectual property is created.

Should patch
Threat actors are really only after two percent of your environment. The must-patch group is likely half of that two percent. So, what is the other one percent? Think about the threat actor kill chain and what threat actors do to gain persistence, escalate privileges and move laterally. While this 1 percent is not the final target, they are critical systems the threat actors need to achieve their objectives.

At FireHost, we refer to this as "key terrain." Some examples of this are Active Directory servers, patch management systems (ironic, I know), software distributions systems and any other system that allows a threat actor to escalate privileges, create accounts and spread laterally. It's best practice to scan and patch these systems weekly, making them a hard target.

On the tail end of this bucket of "should patch" is everything else that you can patch. The residual from this group should be servers you need to do business, but have workloads that are not an existential threat to the business if breached. Understand that you may not get to all of the servers in this group in a timely manner.

Can't patch
Yes, at the end of this organizational effort, you may be surprised you have systems that can't be patched. Some examples are legacy databases that used to run on mainframes and critical infrastructure/SCADA. A really bad situation? If you end up with systems that can't be patched that house or interact with regulated data. That will not allow you to achieve compliance and puts your business at risk. If your analysis comes to this conclusion, this becomes a business risk that must be addressed, usually with a significant investment.

The focus of a sound security strategy is to make the surface attack so small that it drives up the skill level of the attacker to exploit the environment. The cornerstone to this strategy is an organized effort for patching vulnerabilities. This is not the sexy technology that security folks like to talk about post-breach, but this truly is the best way to have a significant impact on your security posture.

Jeff Schilling, a retired U.S. Army colonel, is Armor's chief security officer. He is responsible for the cyber and physical security programs for the corporate environment and customer-focused capabilities. His areas of responsibilities include security operation, governance ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Author
2/11/2015 | 2:33:23 PM
Re: Great article - Now can I have my playbook back please!!
thanks for the feedback, great minds think a like!  It truly is a wicked problem, legacy applications and databases that the business can't live without, but the security team can't secure.  

User Rank: Ninja
2/11/2015 | 11:03:26 AM
Great article - Now can I have my playbook back please!!
Seriously good article Jeff.

It may be that be both come from a military background that we view patching of systems in the same, almost exactly the same, manner.

To be honest, when it comes to vulnerabiliy remediation, my team spends 90% of our time on 10% of those systems that owners claim cannot be patched/reconfigured.  My management wonders why we are working on these issues so much.  To them, much of this effort seems borderline wasteful. 
But all I have to roll out is the classic "due dilligence" and "due care" mantra.  If we try, and continue to try, we are far better off than if we didn't try or give it a half-baked attempt.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...