Triage & Manage Vulnerability Gracefully

It is Patch Tuesday again.  And what comes to the mind are likely those IT support woes below. 

1. You are in the catch-up game as there is still a backlog of patch releases not rolled out. This release will go into the queue.
2. You know high severity patches need to be rolled out as soon as possible, but no one is giving direction, so it is a first come, first served approach.
3. You wanted to escalate the patch to roll out fast, but no one to give advice and support your decision. In the end, fingers pointing at you for any delay and you're the one to take up the risk of the lapse if testing is not duly done.
4. You are always asking application stakeholders to test within the allocated windows period, but normally it is missed and the coordination just overwhelmed you and your chase on status updates. Too reactive and slow to respond.

In fact, these are not surprising and you are definitely not alone. A vicious cycle ensues. The morale of the IT support teams gets worse leading to higher attrition. The Organisation inundated with many other security patches, e.g. Adobe, Java, OpenSSL, Drupal, Cisco etc.) and the number of non-patched machines will go uncovered. Inadvertently, the Organisation is exposing herself in a totally vulnerable state inviting opportunistic attacks.  

To get ourselves off this dire state, we need to end this and adopt a strategy to address those woes holistically. For example, have a vulnerability management strategy to TRIAGE the patches and get management to be serious about this. Below is my proposed high-level TRIAGE strategy and the supporting element to get this whole regime going.

Time of Essence 

Objective - To get the patch information readily disseminated and watch out for other potential threats (in the wild) that are exploiting the vulnerability, ie. typically tagged by Common Vulnerability Enumeration, CVE). 

Metric as guidance  - Time to respond (within one to two days). Updated targeted sender list. 

Supporting Element - Security Operation Centre is a designated operational entity that functions as a nexus to centrally manage all the information sharing e.g.  receive and share out to the stakeholders like project teams and system owners to keep them up to date. Build up this team or identify one existing IT support team that can assume this role. The core nature of its role & responsibilities would be to maintain continuous monitoring that (ideally) operates 24 hours, 7 days a week.  

Example - When the public news announced a new vulnerability. The SOC team will get into its act by checking if there are patch releases from the affected vendors. Send out an advisory to the project team and system owner for necessary action. The SOC team will continue to keep watching and providing regular updates of the threat development and assess the damage extent, e.g. any sighting of real attacks and the targeted services relevant to the Organisation. 

Review Impact 

Objective - To make sure the vulnerability (CVE) are each reviewed with a severity score so that action can commensurate based on priority as per an established patch deployment plan. Adopt a risk-based assessment approach to get a patch implemented and established governance oversight with stakeholders designated as the approving authority committee.

Metric as guidance - Common Vulnerability Scoring System based scores. Time to implement upon patch availability. Approval platform for Residual Risk acceptance. Reporting on Critical / High CVSS score. 

Supporting Element - Steering committee will be designated to oversee the vulnerability management regime and policies (below). It serves as the platform for system owner or project teams to seek approval when time to patch needs to be extended. A regular update on critical and high severity patches are also compiled and reported on this platform. 

Example - Reference to the CVSS scoring, the base score is calculated online which is in reference to the "tree" below. It is based on the score, and from it to comply to a set of stipulated times to patch. The policy needs to mandate this strict regime as a baseline, such that in the event there are cases where the project team cannot comply due to operational impact, it needs to go back to the Steering committee for approval and ensuring the committee performs due diligence in implementing mitigation measures are taken.

Asset - Gather Evidence

Objective - To identify all affected assets which can be IT or OT (operational) based. Activate the response plan to reduce the exposure with mitigation measures put in place first while waiting for the finalized patch releases. On release make available, verify the remediation actions are effective and assured by gathering evidence on the vulnerability being closed.

Metric as guidance - Affected asset map - Count of the patched and non-patched asset. Scorecard of patching effectiveness - count of faulty patch or service outage due to patch roll out. An annual trend on the time to patch compliance.

Supporting Element - Technical SME to provide leadership in generating the scorecard report for updating the steering committee, and importantly oversee and guide IT support teams in running vulnerability management technology. Automated retrieval of the patch status is implemented as compared to solely depending on manual polling of patch status that can be prone to error and take longer to get an update. 

Example - The SME is designated the architect of the IT Support committee that procure a Vulnerability Management solution that can be flexible to be agent or agentless based to track the asset patch compliance level. When SOC send out an advisory, the IT Support gets into the VM dashboard to import the vulnerability map and generate a snapshot of the asset affected. 

Based on the exposure of the asset, the critical service that is highly dependent on other systems will need to have an action plan to schedule during the next downtime or earlier based on time to patch. Thorough testing with all stakeholder applications may require an extra time buffer on top of the patch roll out. For a non-IT based asset, the patch may not be readily available and similarly, SME will advise the mitigation action to be put in place and SOC is to monitor for anomalous activities and respond swiftly to inform the stakeholders. 

Conclusion

There is no magic to adopting the TRIAGE strategy. It is sheer hard work, iterative process refining and soliciting buy-in from the management to preach how the current situation can improve and comply with the requirement.  In short, the Organisation is safer with a better watch over the patching status. It is going to be tough at first but it will change as you establish a clear KPI outcome and institute a sound decision-making process. Technology as the enabler is a success factor too.  

I hope this article has helped you to picture what is a possible mean to TRIAGE vulnerability in a managed fashion.