Over the past few weeks since this vulnerability was made public much has been written by many on what your organization should do about it. This is not the end of the story; Apache has already released 3 patches for related vulnerabilities, and you need to be ready for the next one when it arrives. With the beginning of 2022 now is the time to step back and review how well your organization met the challenges that this posed. What will your new year’s resolutions be? In this blog, I will outline some of the questions that you should ask yourself.
How well did your cyber incident plan work?
New vulnerabilities are discovered all the time – you need to be prepared.
- Were you able to assemble the incident response team in good time?
- How did you decide on the business risk that this posed?
- What was the business objective of your response and was it achieved?
Could you identify systems at risk?
You can only protect what you know you have: do you have a complete inventory of your IT assets?
- How easily were you able to identify the applications, systems and devices that could have this vulnerability?
- Did your software vendors inform you of the status of their components and provide recommendations?
- Did your vulnerability scanning program identify the systems at risk in a timely manner?
- How easily were you able to identify the business criticality of the applications, systems, and devices affected to make an informed decision on the next actions to take?
- What action did you take for vulnerable components (remove, block, suspend, patch, or ignore), and how well were these actions implemented?
- Did you involve any partners and if so, how well did they perform?
How well did your SOC perform?
Your SOC should be able to detect threats – how well did it perform?
- How well did your SOC perform – did you detect any active threats or exploits of this vulnerability?
- Was your SOC able to monitor for evidence of traffic indicating the existence of the CVE?
- Did you actively hunt for evidence that this CVE existed and was being exploited?
- Did your SOC discover any at-risk applications, systems, and devices that were not otherwise known?
- How well were you able to contain, recover, and restore impacted services?
Do you need to Review your Policies?
Most organizations are using third-party components – what are your policies around the risk associated with these? These include the use of Open-Source software, the use of common libraries as well as bespoke software developed just for you.
Do you need a software dependency catalogue?
Having a catalogue of software dependencies helps to quickly identify which systems are at risk when a new vulnerability is discovered.
- For internally developed software, do you have an up-to-date software dependency catalog that includes a clear record of all software components?
- For vendor-provided software and services, does the provider:
- State which external (such as Open-Source) components form part of their product?
- State the level of support that they provide for these components? What action they will take when vulnerabilities are discovered and within what timescales?
- Note that these include IaaS, PaaS (such as managed databases) and SaaS?
- State their liability for damage caused as a result of these components? For example, insurance against cyber damage caused through the exploitation of vulnerabilities in these components.
What level of Software assurance do you have?
What level of software assurance is right for your business-critical applications? Depending upon the business criticality of the system/application/devices, consider the level of assurance required.
- For critical applications require ISO/IEC 15408 Software Evaluation
- Other forms of independent certification (such as PCI-DSS, HIPAA, ISO, etc.)
Do you implement Secure Software Development?
Does your internally developed or commissioned software process identify and remove common vulnerabilities based on at least those catalogued by MITRE ATT&CK®, CVE, and OWASP Top Ten Web Application Security Risks?
Which of the following best matches your internal software development?
- Use Secure Software Lifecycle Development Methodologies
- Use code scanning tools – including code from Open Source
- Use dynamic vulnerability scanning – including for externally provided libraries
- Use external penetration testing
- Use formal evaluation based on ISO/IEC 15408
In case you want to dive deeper into the topic of how to respond to cyber incidents, have a look at our Master Class on Incident Response Management. If you are looking for tools in the area of Security Orchestration, Automation and Response (SOAR), our Tools Choice will help you define a shortlist of vendors.