Understanding the vulnerability posture of an organisation at a basic level helps you drive remediation efforts.
So, I don't know what to call this information but I have decided to call it 'Vulnerability Posture' 😄Let's consider an organisation 'ORG' which manages infrastructure security for a 'CLIENT' and let us assume the 'CLIENT' has a total of 700 vulnerabilities.
So, here is how one can split the vulnerability data:
1. Total - 700 (ORG Managed - 500, ORG Unmanaged - 200)
2. ORG Managed - 500 (Non-EOL - 400, EOL - 100)
3. Non-EOL ORG Managed - 400 (OS - 250, Non-OS - 150)
4. Non-EOL ORG Managed OS - 250 (Server - 50, Network Devices - 25, Network Security - 25, Workstation - 150)
5. Non-EOL ORG Managed OS Server - 50 (CLIENT independent - 40, CLIENT dependent - 10)
Now, you should understand the split of 40 by the type of OS i.e. whether Linux or Windows, similarly for Workstation.
6. Non-EOL ORG Managed non-OS - 150 (CLIENT independent - 100, CLIENT dependent - 50)
Similarly for non-OS, the split of 100 by type of applications i.e. Browsers, PDF Readers, Microsoft Office, File Compression Apps, Java/.NET framework (at least top 5).
Points to ponder 🤔
1. Why does ORG has unmanaged assets?
2. What is the action plan for EOL assets?
3. In CLIENT's environment, how many new vulnerabilities appear and how many are remediated every month?
4. Are there vulnerabilities/assets which are part of any exception?
5. What is the patching cadence for CLIENT? Is it monthly or quarterly?
6. Why do some vulnerabilities have dependencies on CLIENT?
7. Is there a formal agreement on dependencies between ORG and CLIENT?
Outcome:
Once ORG understands the vulnerability posture of CLIENT, ORG will be able to identify key challenges in remediation efforts.
Once the challenges are identified I don't need to tell about the next course of action 🫡
Happy Learning !!
VulnerabilityManagement CyberSecurity
No comments:
Post a Comment