Why You Must Prioritize IT Vulnerability Risks

Why You Must Prioritize IT Vulnerability Risks – A common sense explanation.

  • Why should you prioritize the risks in your IT network?

  • Why can’t you just fix ALL the problems?

Unless you work in a company that has unlimited resources and you have absolute support at all levels for remediating the vulnerabilities in your environment, you MUST prioritize the issues that cause the most risk to your IT environment.

 

Analogy.. “The To-Do List”

Say your wife gives you a list of 150 things to get done on a Saturday afternoon.. How many can you realistically get done? Maybe 5? Maybe 10 if the tasks are small.

If you have a large network, you likely have many possible vulnerabilities. Say you have a relatively small list of 300 security issues found from vulnerability scans and other security assessments and tests.. Can you realistically expect all the teams that would own fixing those issues to drop everything they are doing and fix the “list” of issues you give them?

How much security remediation work can you really expect to accomplish? The answer for these types of questions is more dependent on how your organization functions than on any calculations or math.  Every IT shop is trying to fight for resources to..

1) Implement customer projects.

2) Upgrade and/or modernize their own infrastructure.

3) Implement their own strategic initiatives.

4) Have a work/life balance.

 

Where does that leave working on tasks to fix issues that have been found through security testing?

The naive answer is to say that security should always be a top priority and the teams should figure out a way to get the work done. For those that work in the real world it simply is not that easy.

Resources such as budget, hardware, and time is limited. Some IT shops are fighting to survive. If they have to stop business driven projects for 3 months to fix security issues their business customers may choose to use other options.

What is the answer?

The answer is to use Risk Analysis and Risk Management techniques to determine what the highest risk vulnerabilities are to your IT environment. This is called using a “Risk Based Approach.”  Simply put, it means to fix the most risky things first. You would think this is common sense, but you would be wrong. There is often a reflexive response to any type of possible security issue. The reflex response is “just fix it”. If there are 5 issues, then just fix them. If there are 200 issues, then just fix them.

The problem is that most decent sized companies will have many possible issues. You simply can not have a completely secure environment without making the environment unusable.  I go back to the example of having a list of 150 tasks to complete in one day. It simply isn’t possible. However, could you get 5 done? Probably so. Could you get a small amount done on 20 tasks? Probably so.

So which one is better? Getting 5 security issues completely resolved or 20 issues partially completed in a year? That needs to be a management decision based on good risk analysis of the issues.

Fixing security issues is an effort like any other.

The whole point of this post is to get you to understand that resolving security issues is no different from any other project or effort. No company or organization can implement every good idea. They must prioritize in order to get the best results from their efforts.

Resolving security issues is a work effort just like any other in an IT organization. The effort must be prioritized against all other efforts so that they can get the proper focus and funding. If you don’t have focus on a few things, then you get very little accomplished, and your efforts are spread thin.

Final Analogy… Pruning…

Every organization is like a rose bush or a grape vine. In order for nutrients to allow the main stems and fruit to truly mature and reach its full potential, you must prune the small branches and vines that use up the resources of the plant that don’t add any fruit or flowers. The small branches use energy and resources, and eventually will cause the plant to be poor producer of fruit or flowers. Why? Because no focus was devoted to the things that mattered.

Final Point : To get things done, you must prioritize and be able to focus your energy and effort on what matters most.

NorthWest Arkansas ISSA Presentation

I’m giving a high level presentation over the PCI-DSS requirements around Vulnerability Management and Penetration testing for our April 5 ISSA meeting.

Most of the details will be in Q&A and discussion. So don’t expect a lot of deep content in the powerpoint slides linked below.

PCI_Vuln_Pen_ISSA_March_2011_ppt

The meetings are typically held on the first Tuesdays of each month at Whole Hog Cafe. A great Memphis style barbecue restaurant in Bentonville Arkansas.

Vulnerability Management – Continuous vs Batch

Reasons why a “Continuous Vulnerability Assessment and Remediation” process is better than a quarterly scan or “batch” process.

Continuous Security

“Continuous Compliance” is a fairly hot security topic. The word “continuous” has almost reached a buzzword status when it comes to information security topics like vulnerability scanning and application security.  So I decided to look around at some of the products and pages on the Internet that cover this topic. I found some explanations of what continuous compliance is and products that supposedly do it. However I didn’t find anything that went in depth to explain why continuous compliance is better in regards to security vulnerability discovery and remediation.

I felt that I knew why it was better, but I always like to do some research to validate my assumptions. I hope you do also.  Below I use “Continuous Vulnerability Management” as a synonym with “Continuous Compliance and Continuous Configuration Management.

Where Is The Answer?

I didn’t find the explanations and answers I was looking for in vulnerability management topic pages or security focused blogs. I remembered from my undergrad and MBA operations management classes that continuous is typically better than batch, so I figured business and operations management topics would hold the hard answers I wanted to find.

BINGO!  I found the answers on Operations Management and Real-Time Business Intelligence type forums and websites.

I’ll summarize my findings below.

Benefits of Continuous vs Batch

  • Once you start a continuous process, you can run it constantly. There is no need for setup and tear-down times. This removes the wasted effort of having to regularly spend time ramping up discovery and remediation efforts, and spinning those efforts down, just start them over again.
  • Continuous allows you to use less resources to complete work because the work is spread out as needed into smaller more manageable chunks. Instead of delivering a bunch of findings every few months, the findings are delivered or “pushed” immediately as they are found. Theoretically, this may allow vulnerability owners to just “work in” remediation work with other support tasks instead of having to focus on large lists of findings.
  • Continuous vulnerability management should be more scalable. Due to continuous vulnerability management requiring less overall resources at any one point, it should be easier to get more overall work done by allowing a person to break out a large amount of work into manageable chunks or more easily add resources to remediation efforts.
  • Continuous should cause less disruption to regular business operations and support. In order to support continuous vulnerability management, it must become a part of your normal operations and support. I can tell you from experience that when you deliver a large list of findings once every few months, the vulnerability owners act like it is a surprise each time for a few years, or at least hope you will forget about them.
  • Continuous vulnerability management should create less risk for business impacting issues due to configuration changes. This lowering of risk is due to vulnerability remediation work being completed in smaller chunks of work instead of trying to cram tens or hundreds of configuration changes or patches through in a short amount of time.  Experience shows this “cramming”  usually results from a large “batch” style list of vulnerabilities.
  • Similar to the reasoning above, continuous vulnerability management should have fewer errors than batch processing because remediation work is done in smaller chunks. The smaller work units should allow for more focus on each individual work unit, instead of the feeling of being rushed to get a large batch of work completed in a short amount of time.
  • Root Cause Determination should improve. In continuous vulnerability management you have much shorter amount of time between when a vulnerability is created and when it is found. It is simply easier to remember (or to track down) what someone did yesterday than what was done weeks or months ago.

Bottom Line? Compliance & Security Improves

  • All of the above reasons contribute to a cumulative improvement in the efficiency of a continuous process over a batch process in regards to vulnerability scanning and remediation. The cumulative negative effect of the individual latencies in a batch style or “90 day cycle” method of vulnerability management cause that method to be less efficient, less secure, and to cause more disruption to an organization than continuous vulnerability management.

So why doesn’t everyone do Continuous Vulnerability Management instead of Batch or Cycle Style Method?

There are some requirements you must meet in order to successfully implement a continuous vulnerability management program. These requirements are not usually cheap or easy.

  • Requires Constant or “Continuous” monitoring

Sound easy? It isn’t for large organization that may have millions of possible IP addresses. You must spend a lot of time and effort in order to get systems setup that can continuously monitor your entire vulnerability footprint. The larger your organization, the harder this requirement will be to implement.

  • Requires near real-time status updates

The ability to scan for vulnerabilities continuously and the ability to report on what has changed from one day to the next is getting much more feasible to accomplish. Some modern vulnerability management systems will keep track of what has changed for you. This “continuous” updating is needed to truly understand when vulnerabilities are found, and when they go away. Without this seemingly simple capability, you must stay in batch mode.

You also need the ability to throw out the vulnerability findings you don’t care about, and figure out which ones you do in a very streamlined or automated fashion. Otherwise you get overloaded with useless data, and the important findings get less focus.

A side-bar to this requirement is that you need reporting and analysis on your data.

Constant remediation can hide pervasive issues unless adequate analysis and trending is performed on discovered vulnerabilities.

Continuous is also all about continuous improvement. Without the ability to analyze and trend data, you are not leveraging continuous compliance/vulnerability management  methods. You probably are not getting the visibility or management support you need without this reporting.

  • Self-Service and Automation Required for Mid size or Large organizations.

This gets even harder. You must automate. Taking raw vulnerability findings from scanning systems and software and turning those into actionable items is very difficult.

If you have hundreds of thousands of systems, and hundreds of possible owner teams, how do you easily or quickly know who owns each vulnerability? If you have a CMDB that has all this mapped out or only have a few thousand systems then great, that is a good start.  Manual analysis of findings from spreadsheets and then sending those spreadsheets out to the owners is not continuous, it is a batch style scenario.  The only way to move from that batch style scenario is to apply logic and rules to your vulnerability data so that the owner for the item and the decision on whether action is needed is automated. Some type of ticketing system that flows the work down to the owners is typically needed.

Organizations with immature vulnerability management and security practices will probably need to remain in a batch style method of vulnerability management until they can meet the above requirements.

Downsides to Continuous vs Batch?

  • Some types of changes or implementations can be done more efficiently in batches.
  • Some organizations may perform better using a batch style method of vulnerability management.

Some of the other topics that seemed to back up the continuous approach..