Vulnerability Management - Understanding vulnerability posture

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 !!
hashtag#VulnerabilityManagement hashtag#CyberSecurity

Vulnerability Management - Rapid7 InsightVM typical architecture

I was bored by repeatedly using low end applications, so today, I thought to use a very sophisticated and complex application .. MS Paint 😁 .

So, a typical Rapid7 InsightVM high level architecture looks like as depicted in the attached image.

1. InsightVM agents reports to Rapid7 platform.
2. Scan engines reports to security console.
3. Scan engine communication methods (https://docs.rapid7.com/insightvm/scan-engine-communication-methods/)
4. InsightVM agent requirements - Network traffic and connectivity (https://docs.rapid7.com/insight-agent/network-traffic-and-connectivity-requirements/)
5. Security console system requirements (https://docs.rapid7.com/insightvm/system-requirements/)
6. Security console is always in sync with Rapid7 platform as it has to upload data collected by scan engines to the platform and download agent data from the platform.
7. Rapid7 platform endpoints can be more specific depending on the data storage region for a particular organization.
8. Agents receives product and content updates from *https://endpoint.ingress.rapid7.com/. Scan engines and security console receives product and content updates from updates.rapid7.com.


Happy Learning !!
hashtag#VulnerabilityManagement hashtag#CyberSecurity hashtag#Rapid7

Excel VBA - Trick for large macros

Sometimes, you break a large process in multiple macros to modularize it. By doing so, maintenance, testing and debugging becomes easy. In order to get the desired output, you need to run these macros individually in order. Consolidation i.e. an effort of combining these macros in a single macro can become challenging (especially if LOC of macros is large).

In scenarios where you do not want to make changes in the frontend and backend of these macros, you can create a master macro and invoke these macros through the master.

Happy Learning !!
hashtag#VulnerabilityManagement hashtag#VBA hashtag#MSExcel hashtag#Cybersecurity