CISO

Enterprise Information Security

The rat race of vulnerability management

by Leave a Comment

Patch management is one among the major IT Security concerns most of the organizations are worried about. It is practically not possible to have a 100% of the IT infrastructure patched with all patches released by all the software vendors in the environment. Following are some of the key challenges faced by the organizations in achieving higher compliance towards the patch management

  • IT environments are heterogeneous with various software vendors are having different patching mechanisms
  • In addition to the operating systems, applications,application servers and application plugins are required to be patched as and when there are vulnerabilities identified. How often you patch Acrobat reader or 7 zip? What about that apache server running a small interface application?
  • Many Open source software tools have less reliable patch management mechanisms. How about a fork developed for a specific application? What about the application developed by an independent consultant? What about the support guarantees and vulnerability management clauses in the same? Not many open source companies are providing dedicated support. How about a particular plugin of your favourite open source content management system like Drupal, WordPress, Joomla or any similar ones? What if the plugin is already abandoned by the developer?
  • Limited understanding of IT Administrators about a specific patch as to whether it is applicable in the environment or not. DBA.s often consider that some of the patches are not applicable for the database they are running even though the vendor recommends the implementation.
  • Lack of effective coordination with IT and business functions like application administrators, DBAs, end users, business owners etc for applying specific patches like Oracle (DBA is concerned about it), IPS (business may not want a down time), Online Banking application (downtime & new compatibility is a concern for business) etc. It is true that many of the concerns can be tested and validated by respective group of people before patching the production systems; however, many consider it as a risk (from availability perspective) to apply patches in the production unless it is proved as a requirement.
  • Compatibility issues of underlying software. This is especially applicable in the case of browsers. Let us assume one of your application requires 2 months time to get it upgraded so as to have compatibility with the latest browser upgrade? How is it handled?

No software companies are releasing new versions of the software in every 6 months. So what are there software developers are doing? Most of them are developing patches for the weaknesses identified and release patches very often. Now, the challenges of an IT Security professional is to cope up with the above challenges and protect the organization from the vulnerabilities which are not patched, but publicly announced (many times the zero day ones as well). The organizations patch cycle may not meet the vendors patch release. For example, Patch Tuesdays from Microsoft are monthly. Adobe and Mozilla talks about it once in two weeks. Chrome does it much often. Then we have other vendors which does it on ad-hoc basis.

It is a very difficult process to maintain high patch management level This leaves the organization into partial darkness when it comes to vulnerability management. There are many solutions offered by software vendors, however, many of them work in isolation. For example, WSUS from Microsoft addresses only the MS patches and not acrobat or flash. Not many solutions address the application patches or *NIX patches. Databases patches are another in the list. Virtual patching is another solution put forward by many vendors to address majority of these problems.

IT IMHO, it is important for an organization to have a comprehensive Vulnerability Management plan which addresses most of the above challenges. The solution should address the requirements such as:

  • Discovering the vulnerabilities
  • Assess the vulnerabilities
  • Remediation of the vulnerabilities
  • Assess the compensating controls
  • Assess the post effects of the new patches

What are your thoughts on this? What are the challenges in your opinion and how often you get into this rat race?

Seccubus Vulnerability Scanner

by Leave a Comment

Seccubus is an automated vulnerability scanner with some extra features. One is that the periodic vulnerability assessment capability of the tool. Seccubus was created in order to more effectively analyse the results of regular scans of the same infrastructure by efficiently interpreting results.

How does it work?

Seccubus runs scans at regular intervals and compares the findings of the last scan with the findings of the previous scan. The results of this comparison are available in a web GUI
Findings have and can be tagged with one of the following statuses:

New
Finding was detected for the first time

Open
Finding was previously detected and has not been altered by the user

Changed
Flinging has changed since it was last detected. This status remains until it is changed by the user

No Issue
The finding does not pose any security risk and will remain this status until it changes. If the finding changes it will be marked as changed.

Gone
The finding had been found in a previous run, but has done been fixed in this run.

Fixed
The finding has been fixed and should not reappear. If this finding reappears it will be marked as changed.

Hard Masked
The finding is bogus and will not leave this status unless the user changes it.

Because the number of reported findings from Seccubus, especially on the second or later run, is much smaller then the number of findings of a regular scan, there will be much less time involved in the analysis of subsequent runs.