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

2/11/2015
10:30 AM
Jeff Schilling
Jeff Schilling
Commentary
Connect Directly
Facebook
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Jeff.schilling
50%
50%
Jeff.schilling,
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.  

Jeff
aws0513
50%
50%
aws0513,
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.
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
The Cold Truth about Cyber Insurance
Chris Kennedy, CISO & VP Customer Success, AttackIQ,  11/7/2019
Black Hat Q&A: Hacking a '90s Sports Car
Black Hat Staff, ,  11/7/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
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5230
PUBLISHED: 2019-11-13
P20 Pro, P20, Mate RS smartphones with versions earlier than Charlotte-AL00A 9.1.0.321(C00E320R1P1T8), versions earlier than Emily-AL00A 9.1.0.321(C00E320R1P1T8), versions earlier than NEO-AL00D NEO-AL00 9.1.0.321(C786E320R1P1T8) have an improper validation vulnerability. The system does not perform...
CVE-2019-5231
PUBLISHED: 2019-11-13
P30 smartphones with versions earlier than ELLE-AL00B 9.1.0.186(C00E180R2P1) have an improper authorization vulnerability. The software incorrectly performs an authorization check when a user attempts to perform certain action. Successful exploit could allow the attacker to update a crafted package.
CVE-2019-5233
PUBLISHED: 2019-11-13
Huawei smartphones with versions earlier than Taurus-AL00B 10.0.0.41(SP2C00E41R3P2) have an improper authentication vulnerability. Successful exploitation may cause the attacker to access specific components.
CVE-2019-5246
PUBLISHED: 2019-11-13
Smartphones with software of ELLE-AL00B 9.1.0.109(C00E106R1P21), 9.1.0.113(C00E110R1P21), 9.1.0.125(C00E120R1P21), 9.1.0.135(C00E130R1P21), 9.1.0.153(C00E150R1P21), 9.1.0.155(C00E150R1P21), 9.1.0.162(C00E160R2P1) have an insufficient verification vulnerability. The system does not verify certain par...
CVE-2010-4177
PUBLISHED: 2019-11-12
mysql-gui-tools (mysql-query-browser and mysql-admin) before 5.0r14+openSUSE-2.3 exposes the password of a user connected to the MySQL server in clear text form via the list of running processes.