You gear up for another exciting day in infosec, walk into your building, sit at your cube and open up your email. If you’re like me you also browse social media feeds for the latest news in cybersecurity. That is when you see it, the next named bug…..heartbleed, shellshock, poodle, ghost, and now badlock. You sigh, kick and scream, throw your coffee at the window and then begin to handle emails and calls coming in from people asking about it, first off……

If you have been in the field for any amount of time this is a very common occurrence. Your entire day can get turned upside down by one of these. Someone reads about a vulnerability in the news and begins to freak out about it. Just take a deep breath and remember that you’re the security experts and it is up to you to determine the impact to your systems. Even if the media is blasting a vulnerability everywhere it doesn’t mean the apocalypse has come.

If you haven’t read the previous post by Matt SDLC: A Strained Relationship, then you should. Don’t start shooting the messengers but instead let them know you will have a report on it shortly. Remember that we want to work with our new friends and not push them away. If you come off as a jerk then who is going to actually fix the issues?

You should have a process in place for these disclosures but if not you can use some basics I outlined below. Lets break it down piece by piece and then figure out what should be done. Remember that information is power and the more you understand the better equipped you are to handle the issue.  Below are some general guidelines, by no means definitive, every situation and network is different.

• First you need to identify the vulnerability.
  • What does the vulnerability do?
  • What can be gained by exploiting it?
• How easy is it to exploit?
  • Are there exploits in the wild?
  • Does it take a genius or a beginner?
  • Can it be done remotely?
• Now identify the scope.
  • What OS does it affect?
  • What services does it affect?
• How do we fix the vulnerability?
  • Does it need a patch, a configuration change, or can another mitigating control be used?

The Best Scenario

Let’s run an imaginary vulnerability, Softtop (I can make funny names too), through this check on my lab environment.  My systems consist of Windows 7, 8, Ubuntu 14.4, a Windows 2008 Web Server and a Windows 2008 Domain Controller. All of the systems except the web server are internal and behind a firewall.

• Identification – It exploits connections over SSH allowing a malicious user to gain access to limited files on a unix box.
• Exploitation – There are currently no exploits in the wild and it takes a high level of knowledge to exploit, however it can be done remotely.
• Scope – All linux boxes are affected that are running SSH.
• Remediation – You can disable SSH or apply a out of band patch from the OS vendor. It will however require a restart of the service.

So looking at this I can say that the majority of my systems are not affected. My Ubuntu box actually happens to be running SSH but it is internal and behind a firewall. Do I trust my internal users? Of course not, I don’t trust anyone! But for all intents and purposes this vulnerability can wait till after hours to be patched. With no known exploit and the system being protected from the outside world I am not very concerned, a Low Likelihood and Low Impact scenario.

If it is a critical server that cannot afford an outage at this time I might not be stopping business for a vulnerability that takes extreme effort to compromise either. This is what you would call Low Likelihood and High Impact, but this is a call you have to make.

The Other Scenario

Now what if all my boxes were affected, or one was external, or the vulnerability was easily exploited, a High Likelihood and High Impact situation. This is a whole other animal, but again…..let’s not freak out. You did your analysis right? Get it into an easily understood format, be sure to identify what systems are affected and provide a solution. If you don’t give them a solution then I guarantee they will come back and ask for one. Communication is key and the system owners will appreciate your analysis and solution.

From here it is up to your company, environment, culture etc. to decide how fast things can be fixed. It might be rough at first but over time you will establish a solid process and be used to this type of thing. Also you will be receiving feedback from people, do not take it as a negative. Use this information to improve upon the process on your next go around.

The short story here is not to be drawn into the emotions and hype of the media. Use a defined process to effectively identify the scope of a bug and how it affects you. Stick to your process and make small adjustments as you need to, but just because everyone is freaking out it doesn’t mean you should. And as always, keep learning, until next time….