ISACA Moscow Vulnerability Management Meetup 2017. Last Thursday, I attended a very interesting event entirely dedicated to Vulnerability Management – open ISACA Moscow meetup. Me and my former colleague from Mail.Ru Group Dmitry Chernobaj presented there our joint report “Enterprise Vulnerability Management: fancy marketing brochures and the real-life troubles”.

The number of registered participants totaled 120. As I can tell looking at the photo below, there were about 80 people in the hall after the second presentation. For a highly focused local information security event, it’s a lot. According to the organizers, it was the largest ISACA Moscow meetup. Thanks to everyone who came!

I would like to mention a well-structured agenda. There were 4 presentations arranged in order: from the most theoretical / methodical to the most practical. And our presentation was the last one.

Oleg Boyko started the event. He was talking about the place of Vulnerability Management in COBIT 5 framework. I don’t know COBIT good enough to comment on this. The main thing I’ve noticed is that among the 37 COBIT 5 processes, there is no a process for managing the vulnerabilities, such as Manage Assets or Manage Configurations.

I also liked his example that Vulnerability Management metrics may be used as quality indicators for software developer teams in your organization. It’s may be useful if your Top Management keeps skeptical about all the hacking threats.

Then Dmitry Ogorodnikov was talking about Vulnerability Management in terms of ITIL (and SANS).

He formulated the roles in the VM process and described in detail the phases of the VM process based on SANS “Implementing a Vulnerability Management Process“. I liked his statement that if you set proper roles, then process may start functioning  automatically.

The roles:

• Security Officer: The security officer is the owner of the vulnerability management process. This person designs the process and ensures it is implemented as designed.
• Vulnerability Engineer: The vulnerability engineer role is responsible for configuring the vulnerability scanner and scheduling the various vulnerability scans.
• Asset Owner: The asset owner is responsible for the IT asset that is scanned by the vulnerability management process. This role should decide whether identified vulnerabilities are mitigated or their associated risks are accepted.
• IT System Engineer: The IT system engineer role is typically responsible for implementing remediating actions defined as a result of detected vulnerabilities.

So, my current role in the process is a Vulnerability Engineer with an element of Security Officer =)

5 phases of the VM process:

• Preparation
• Vulnerability scan
• Define remediating actions
• Implement remediating actions
• Rescan

In general, it’s very similar to  a real life.

Then there was a short 15-minute coffee break, when I had a wonderful chat with former colleagues and friends from the Moscow InfoSec community. We, in particular, talked about exporting scan results to SIEMs, discussed differed VM vendors and integrators 😉

An finally the practical part started. Ekaterina Pukhareva described Vulnerability Management process in Russian payment service provider QIWI. In fact, it was a story of effective usage of enterprise-level VM solution Tenable Security Center.

It should be noted that QIWI scans the entire infrastructure on a daily basis using a large number of deployed scanning nodes. In the case of SC, it’s possible because you get huge amount of Nessus licenses (512) in a bundle, as I showed in the article “Installing Nessus for SecurityCenter on laptop“. We have a joint presentation with Katya on ZeroNights last year, so the you can see some of her slides at “ZeroNights16: Enterprise Vulnerability Management“.

After it, it was my turn to speak. I was mainly criticizing VM vendors, trying to pay attention to the problems that Vulnerability Management vendors does not mention in their marketing materials.

I would like to turn my speech into a series of extended blog posts in future. Here and now I will outline the main points:

1. Vendors often ignore some uncomfortable questions about Vulnerability Management in their marketing. Otherwise it will be obvious that even an expansive VM solution won’t be a silver bullet.
2. Vulnerability analysis of perimeter, office network and production / critical business systems are very different processes. The number of highly dynamic hosts, typical vulnerabilities, information sources for host inventory and available methods of assessment vary greatly.
3. The healthy relationship between the IS (vulnerability analyst) and IT are very important. The ideal case when there is already a fully functioning patch management process in organization, the worst case, when you need to provide PoC for any detected vulnerability. It is necessary for vulnerability analyst to be able to work in any case.
4. VM-solutions are expensive, because nearly all of them are licensed by ip-addresses. There are cost effective alternatives, but be ready to make some scripting.
5. Vulnerability Scanning is not a commodity. The knowledge bases of scanners are quite different.
6. Prioritizing of  vulnerabilities is a difficult task. It is necessary to consider many factors, not just look at vulnerabilities labeled as “Critical” in scan report.
7. Building diagrams for changing the number of vulnerabilities is not as obvious as it seems. In the case of a highly dynamic infrastructure, the charts needs to be smoothed.
8. Custom automation is needed to update and manage scan tasks, filtering non-critical vulnerabilities, assigning remediation tasks to the right responsible person and building adequate statistics / visualization.

Then was a turn of Dmitry Chernobaj. When we was working together in Mail.Ru Group, he headed the department responsible for patching Windows-based office network. So, Dmitry described the process of vulnerability remediation from IT point of view.

Here are 5 main issues he mentioned in his part:

1. Achieve SLA between IT Security and Sys Admins. Define goals to reach results, otherwise it will not move anywhere.
2. llocate resources for patch management. Not only human, use tools..
3. Dynamical infrastructure. Modern enterprise is always on the move..
4. Rescan should be done using same credentials as a mass scan.
5. Patch installed, scanner still detects vulnerability.

He also shown some examples of manual patching third-party software and promote a cost-effective solution for patch management PDQ AdminArsenal (PDQ Deploy and PDQ Inventory).

Then there was a very interesting series of questions and answers.

The most interesting questions that I remember:

1. What is better: to buy expensive Vulnerability Management solution, to outsource the process or to make your own? My vision: to buy solution with basic functionality and develop your own script for managing and integrations. Expensive solution will not give you desired result out of the box.
2. What to do with vulnerabilities for which there are no patches yet? Use compensatory measures.
3. What is the reason of delay between the moment when vulnerability become publicly known and actual appearance of vulnerability in the scanner’s knowledge base? Internal priorities of VM-vendor and mutual agreements between Software (e.g. Microsoft) vendors and VM vendors on provision the information about vulnerabilities before the actual release of the patch (some VM vendors have such agreements, some of them don’t).
4. Who should clear the vulnerability stream from false positives? IMHO, this is the mission of IS (vulnerability analyst). And you shouldn’t do it not manually, but by developing the appropriate algorithms. It is important not to throw the baby out with the bathwater. Sometimes the most interesting vulnerabilities do not have formal signs of criticality.
5. Vulnerability scanners based on traffic analysis (Passive Vulnerability Scanners), how effective are they?  They are effective for shadow infrastructure detection. But it is still  quite exotic. Alternatively you can receive information on hosts through integration with AD (Rapid7) and log analysis.

So, this was the end of the event. Many thanks to ISACA Moscow and Alex Bodryk personally (on photo below) for the invitation! It was very cool and useful. Also many thanks to the Moscow Polytechnic University for the place for event and great hospitality!

It turned out, the Vulnerability Management is a hot topic in our local InfoSec community. So it makes sense to continue such meetings. Perhaps it’s possible to involve representatives of VM vendors and to touch related topics such as Web Application Scanning and Configuration / Compliance Management (this time only Ekaterina mentioned this).

A few more links to other reports:

• Report in blog of Alexandr Kuznetsov (in Russian)
• Report in Moscow Polytechnic University VK public (in Russian)