Vulnerability Scanning vs Vulnerability Management vs Vulnerability Assessment vs Penetration Testing

Typical vulnerability lifecycle has the following steps:

1. Discover
2. Prioritize Assets
3. Assess
4. Report
5. Remediate
6. Verify

Vulnerability Scanning -> Discover + Scan + Report

Vulnerability Assessment -> Discover + Scan + Prioritize (Asset + Vulnerability) + Report

Penetration Testing -> Discover + Scan + Exploit + Report

Vulnerability Management -> Discover + Scan + Prioritize (Asset + Vulnerability) + Report + Remediate + Verify

Although PT lifecycle is different from VM lifecycle, the steps mentioned in PT are for comparison purpose only. Also as a VM analyst, one has to manage exceptions and analyze false positives which I think can be considered a part of "Remediate" step.

Happy Learning !!

Vulnerability Management - Sudden Surge

Sometimes you would observe a sudden surge in a vulnerability in regular scheduled reports. Also, you would not have observed the vulnerability in past but the first discovered dates are 6 months or perhaps years old.

Following are the points you can consider to find cause of the sudden surge:

1. Scanning vendor changed the severity of the vulnerability

For e.g. Consider a report. The report excluded severity 1, 2 and 3 vulnerabilities. But, severity of the vulnerability was changed from 3 to 4 because of which the vulnerability started appearing in the report. Also, if you shift from one scoring system to another, you can observe such a surge.

2. Scanning vendor changed the detection logic of the vulnerability

For e.g. The detection logic flagged a particular version of a software as vulnerable. But then it was decided by scanning vendor to change the detection logic to exclude the version. But after some time, again the detection logic started flagging the version.

3. Search list was modified

For e.g. Consider a report. The report included a search list as a filter to exclude few vulnerabilities. The search list was modified by a team member and the (QID/Plugin ID) vulnerability was removed.

Happy Learning !!

Vulnerability Management - Vulnerability Detection Pipeline

Received information about a zero day vulnerability from TI team ? Then you checked Qualys KB to find if the signature is published by Qualys or not and found that the signature is not yet released. What will you do now ? Create a case with Qualys to create the signature ? Yes .. You can do that but Qualys also has a platform known as Vulnerability Detection Pipeline which you can refer before creating the case.

The VDP is intended to give users an early insight into some of the CVEs the Qualys Research Team is investigating. It may not show all the CVEs that are actively being investigated. Specific CVE feature requests filed via a Qualys Support case may or may not show up on this page.

Please refer the below links for more information:

https://community.qualys.com/vulnerability-detection-pipeline/

https://blog.qualys.com/vulnerabilities-threat-research/2020/09/16/vulnerability-detection-pipeline-beta

Happy Learning !!

Vulnerability Response

The way we have Incident response, similarly we have Vulnerability Response.

Vulnerability response means to prioritize vulnerabilities that are already being actively exploited in the wild. It is not a replacement for existing vulnerability management programs in place at an organization but instead builds on existing vulnerability management practices.

The below image from one of the CISA playbooks depicts a standardized high-level process that organizations should follow when responding to these urgent and high-priority vulnerabilities.

Identification

Proactively identify reports of vulnerabilities that are actively exploited in the wild by monitoring threat feeds and information sources, including but not limited to:

CISA resources; for example:

CISA/US-CERT National Cyber Awareness System (NCAS) products, which include the weekly bulletins containing vulnerability summaries, and
Note: all agencies should subscribe to NCAS products.30
CISA Binding Operational Directive (BOD) 22-01, Managing Unacceptable Risk of Known Vulnerabilities, which is continually updated with vulnerabilities being exploited in the wild.
Note: subscribe to NCAS products for all BOD 22-01 vulnerability updates, which are announced via Current Activities.


External threat or vulnerability feeds, such as NIST’s National Vulnerability Database, 31 that can also show vulnerabilities being exploited in the wild outside FCEB agencies.

Internal SOC monitoring and incident response, which can detect vulnerabilities being exploited at an agency. Capture additional information about the vulnerability to help with the rest of the response process, including the severity of the vulnerability, susceptible software versions, and IOCs or other investigation steps that can be used to determine if it was exploited.

Evaluation

First, determine whether the vulnerability exists in the environment and how critical the underlying software or hardware is, using methodologies such as Stake Holder Specific Vulnerability Categorization (SSVC). 32 Existing patch and asset management tools are critical and can be used to automate the detection process for most vulnerabilities. For actively exploited vulnerabilities, use the “rapid response” processes in these tools (e.g., CDM). In rare cases, such as one-off misconfigurations and zero-days, additional manual scans may need to be performed. Binding Operational Directives (BODs) or Emergency Directives (EDs) issued by CISA may also list specific technical steps to evaluate whether a vulnerability exists. If the vulnerability exists in the environment, address the vulnerability itself—as described in the Remediation section below—and determine whether it has been exploited in the agency's environment.

Use existing best practices to find signs of exploitation, including:

• A sweep for known IOCs associated with exploitation of the vulnerability.
• Investigation of any abnormal activity associated with vulnerable systems or services, including anomalous access attempts and behavior.
• Completion of any detection processes in CISA directives.
• If needed, collaboration with a third-party incident responder.

If the vulnerability was exploited in the environment, immediately begin incident response activities as described in the Incident Response Playbook.

At the end of the Evaluation phase, the goal is to understand the status of each system in the environment as:

• Not Affected -> The system is not vulnerable
• Susceptible -> The system is vulnerable, but no signs of exploitation were found, and remediation has begun
• Compromised -> The system was vulnerable, signs of exploitation were found, and incident response and vulnerability remediation has begun.

Remediation

Remediate all actively exploited vulnerabilities that exist on or within the environment in a timely manner. In most cases, remediation should consist of patching. In other cases, the following mitigations may be appropriate:

• Limiting access
• Isolating vulnerable systems, applications, services, profiles, or other assets
• Making permanent configuration changes

Existing patch management tools and processes can be used to regularly patch all vulnerabilities. Use “rapid response” processes—as described in the Evaluation section above—in those tools for vulnerabilities that are being actively exploited in the wild. In cases where patches do not exist, have not been tested, or cannot be immediately applied promptly, take other courses of action to prevent exploitation, such as:

Disabling services

• Reconfiguring firewalls to block access
• Increasing monitoring to detect exploitation

Once patches are available and can be safely applied, mitigations can be removed, and patches applied. As systems are remediated, keep track of their status for reporting purposes. Each system should be able to be described as one of these categories:

Remediated -> The patch or configuration change has been applied, and the system is no longer vulnerable
Mitigated -> Other compensating controls—such as detection or access restriction—are in place and the risk of the vulnerability is reduced
Susceptible/Compromised -> No action has been taken, and the system is still susceptible or compromised


Reporting and Notification

Sharing information about how vulnerabilities are being exploited by adversaries can help defenders across the federal government understand which vulnerabilities are most critical to patch. CISA, in partnership with other federal agencies, is responsible for the overall security posture of the FCEB. As such, CISA needs to maintain awareness of the status of vulnerability response for actively exploited vulnerabilities. This awareness enables CISA to help other agencies understand the impact of vulnerabilities and to narrow the time between disclosure and vulnerability exploitation. Agencies must report to CISA in accordance with Federal Incident Notification Guidelines, Binding Operational Directives, or as directed by CISA in an Emergency Directive.

Happy Learning !!

Vulnerability Management - KPIs and KRIs

KPIs and KRIs help you to understand, measure and improve your vulnerability management process and patch management process. They are also essential to create reports and for building a baseline in case you want to implement a SIEM or any kind of security monitoring.

As Vulnerability Management is also a part of a technical risk assessment, the right KRIs could support your security strategy by letting you know where your IT infrastructure is vulnerable, about failed measures or controls and what assets (values) should be protected.

1. Quantitative Indicators

Quantitative indicators are the most common and important types of KPI. They are easy to understand because they just represented by numbers.

• Number of assets (e.g., Windows, Linux servers, workstations, applications, etc.)
• Number of vulnerabilities per type (low, high, critical, exploitable)
• Number of scanned IP addresses / networks
• Number of internet facing assets, applications
• Number of internal and external servers, applications
• Number of scanned URLs

2.  Lagging Indicators

• Results at the beginning of a time frame (found vulnerabilities at the beginning of scan)
• Results at the end of a time period (e.g. remediated vulnerabilities at the end of week/month)
• Historical data

3. Input Indicators

• Time to resolve or remediate a vulnerability
• Number of stuff needed to resolve the vulnerability or patch systems

4. Output Indicators

• Number of vulnerabilities remediated (also by criticality, sytem type, etc.)

5. Leading Indicators

• Trends such as increasing or decreasing number of found vulnerabilities
• Trends in in the criticality of a vulnerability

6. Financial Indicators

• Costs for specific measures to resolve a vulnerability or when a vulnerability caused an incident

7. Practical Indicators

• You can also define practical indicators that are individual or specific to the organization.

Here are some examples of practical KPIs and KRIs.

Detection capability indicators:

• Asset coverage: Scanned assets in comparison with the amount of assets in the scope
• Number of undocumented assets found: Assets that are scanned but not yet documented in the asset inventory (also useful to find rogue devices)

 

Key Risk Indicators:

• Number of open vulnerabilities: total number of applicable vulnerabilities that are not yet analyzed or have work in progress
• Percentage of numbers of open vulnerabilities related to closed issues in a month
• Status and the number of vulnerabilities per asset: status of the remediation progress
• Overview of the remediation solution type: indicate the number of the remediation solution types (patch, config change, etc.)
• Number of open vulnerabilities per business application
• Number of open vulnerabilities per server or system (including middleware and software)

 

Operational indicators:

• Time from detection to remediation per vulnerability
• Remediation done in set timeframe
• Number and reason of failed remediations
• Time to deploy the remediation solution
• Type of remediation solution

 

Process efficiency indicators:

• Number of deployments within and outside of scheduled maintenance windows

Please refer the below link for more information:

https://cyberblend.net/blog/kpi-examples-for-vulnerability-and-patch-management/

Happy Learning !!

Vulnerability Management - Policy Compliance (Evaluation Date, Last Updated Date, Policy Last Evaluated Date) (Qualys)

1) Last Updated (Last Scan Date): 

This is the date of the latest scan when data for control is collected. Thus, every time data is collected for control, this value gets updated

2) Evaluation Date: 

This is the date a control gets evaluated; control evaluation happens as a part of policy evaluation. Hence, this value will be lower (or the same) than the "Policy last evaluated" date.

3) Policy Last Evaluated: 

This is the date when the policy evaluation is complete. This value gets updated every time policy evaluation is triggered for a host.

Now that we know about the types of dates in PC, let's discuss about a situation where you test a control in a policy for an IP address and the control is passing. However it is failing while you are generating the report. What should you do now ? You should evaluate the policy again.

Typically, policy evaluation is triggered right after scan data is collected; however, sometimes due to processing overload, there could be some delay.

If a report is generated for targets before policy evaluation is complete, the "Last updated" value will exceed the "Evaluation date". In such a scenario, users should wait for it to be complete. List of pending processing tasks can be accessed as "PC > Scan > PC Scans > Filters > Processing Tasks...".

Users could trigger the policy evaluation manually as follows:

 "PC > Policies > Edit Policy > (Check "Evaluate now" if not already) Save"

 OR

 "PC > Policies > Policy Data-list > click Quick Actions > Evaluate for a policy"  

Please refer the below link for more information:

https://success.qualys.com/support/s/article/000006635

Happy Learning !!

Vulnerability Management - Date Types

1. What is "First Detected" and "Last Detected" date?

If a QID is detected for the first time (1st Scan) it will be shown in the the "First detected" column.

Now, if the same QID was only detected once and later it was never detected for e.g. the port where the QID was detected was later closed, so the status of "Last detected" and "First detected" date will be same.

If the same QID is detected again in the next scan (2nd Scan) then the last detected date will change to the date when the 2nd Scan was launched or 2nd time the scanner identified the port as open and detected the same QID again.

2. What is "Times Detected"?

The count under "Times Detected" will show how many times the QID is flagged.

3. What is "Last Fixed"?

The "Last Fixed" will show when was the last time the QID was identified as Fixed.

Following are the Vulnerability Status levels:

--> New - The first time a vulnerability is detected by a scan the status is set to New.

--> Active - A vulnerability detected by two or more scans is set to Active.

--> Fixed - A vulnerability was verified by the most recent scan as fixed, and this vulnerability was detected by the previous scan.

--> Re-Opened - A vulnerability was reopened by the most recent scan, and this vulnerability was verified as fixed by the previous scan. The next time the vulnerability is detected by a scan, the status is set to "Active".

4. What is "First Reopened", "Last Reopened" and "Times Reopened" details?

As per the above Vulnerability Status levels, when a QID was "Fixed" and was again flagged (means the vulnerability was found again after the fix) for the first time then it will show the Date in "First Reopened". Now, if the same QID gets fixed and again was "Reopened" in subsequent scan then the details of "Last Reopened" date will get updated and how many times the QID was "Reopened", that count will show under "Times Reopened". 

Please refer the below link for more information:

https://success.qualys.com/support/s/article/000003327

Happy Learning !!

CyberSecurity - Privilege Escalation

We all know what privilege escalation is and it's types. But do you know how it happens ?

Let’s explore three of the most common PE techniques.

1. Manipulating access tokens

This PE technique exploits the way Windows manages admin privileges. Normally, Windows makes use of access tokens to determine the owners of all running processes, e.g. when a thread interacts with a securable object or tries to perform a system task that requires certain privileges.

Adversaries can leverage access tokens through three methods:

a. Impersonate or steal a token 

b. Create Process with a Token

c. Make and Impersonate Token

2. Bypassing User Account Control

UAC limits application software to standard user permissions until an administrator authorizes an increase of privileges. However, this mechanism has security gaps. If the UAC protection level of a computer is set to anything but the highest level, some Windows programs are allowed to elevate privileges or execute Component Object Model (COM) objects that are elevated without prompting a user first. An example of this is use of rundll32.exe to load a specifically crafted Dynamic Link Library (DLL), which loads a COM object that already has elevated privileges. This performs file operations even in protected directories and opens the UAC mechanism to compromise from attackers.

3. Using valid accounts

Adversaries can use Credential Access techniques (e.g. Credential Dumping, Account Manipulation and other) to obtain the credentials of specific user accounts, or steal them through social engineering. 

 

Please refer the below link for more information:

https://blog.netwrix.com/2018/09/05/what-is-privilege-escalation/

Happy Learning !!

CyberSecurity - Metasploit Payload Types

If you look at Metasploit’s payload list, you will also notice that some payloads actually have the exact same name, but in different formats. For example: windows/shell/reverse_tcp and windows/shell_reverse_tcp. The one with the forward slash indicates that is a “staged” payload, the one with the underscore means it’s “single”. So what’s the difference?

Staged payload -> The payload consists of two main components: a small stub loader and the final stage payload. When you deliver windows/shell/reverse_tcp to the target machine, for example, you are actually sending the loader first. And then when that loader gets executed, it will ask the handler (on the attacker’s end) to send over the final stage (the larger payload), and finally you get a shell.

Single payload -> It is meant to be a fire-and-forget kind of payload. This can be used when the target has no network access.

Please refer the below link for more information:

https://docs.rapid7.com/metasploit/working-with-payloads/

Happy Learning !!

Vulnerability Management - Agent Deployment

Below is the link to a blog from Qualys related to agent deployment on remote systems.

https://blog.qualys.com/product-tech/2020/03/24/how-to-install-the-qualys-cloud-agent-for-remote-workforce

Happy Learning !!

Vulnerability Management - Nessus Plugin Types and Categories

Plugin Types ->

1. Remote - Does not attempt/require authentication to the localhost. Instead, it remotely collects information through banner checks, testing for a patch, or exploiting a vulnerability. Some plugins may attempt to sign in to a service, but do not require localhost credentials.
2. Local - Authenticates to a target through a service (e.g. SMB, SSH, etc) and extracts information.
3. Combined - Collects information via remote and local checks. If local checks are unavailable, the plugin will still gather what it can from the remote checks within the plugin.
4. Settings - Defines one or more settings used by other plugins throughout the scan.
5. Summary - Summarizes data collected by other plugins.
6. Third-Party - Runs a third-party application (e.g. nmap).
7. Reputation - Uses a third-party reputation service.

Plugin Categories ->

The plugins below are listed in the order they will run during the scan.

1. ACT_INIT - Sets KB values. Will not send network traffic. These plugins always run.
2. ACT_SCANNER - Port scanner or pings the target
3. ACT_SETTINGS - Sets KB values.  May send traffic over the network. Cannot be disabled.
4. ACT_GATHER_INFO - Non-intrusive.  Generally perform banner grab or send harmless packets to host.
5. ACT_ATTACK - Non-intrusive action which would be considered as an attack by many IDSes.
6. ACT_MIXED_ATTACK - Non-intrusive if safe checks are enabled.  May be intrusive if safe checks are disabled.
7. ACT_DESTRUCTIVE_ATTACK - Intrusive.  Will be noticeable this attack has been run on target.
8. ACT_COMPLIANCE_CHECK - Non-intrusive local configuration check
9. ACT_DENIAL - Attempts to crash service
10. ACT_KILL_HOST - Attempts to crash host
11. ACT_FLOOD - Attempts to flood network
12. ACT_END - Executed last

Note: ACT_DESTRUCTIVE_ATTACK, ACT_DENIAL, ACT_KILL_HOST and ACT_FLOOD plugins are disabled by default. To enable them, disable Safe Checks within the scan policy.

Happy Learning !!

Vulnerability Management - Is vulnerability really fixed ?

You might be providing vulnerability scan reports to platform teams on adhoc basis. Just be careful while sending scan based reports. Why ? .. Because sometimes scanner is able to detect host(s) as live but due to firewall blocking the traffic, it is not able to gather any information. Hence, you will find only few QID/Plugin ID(s) in scan based report but this does not mean that all other vulnerabilities are fixed. 

If you are fetching scan based report for a single host you will be able to easily observe that quickly (firewall hindering network traffic) but for multiple systems, it becomes difficult to spot without proper analysis.

Hence, best is to use host based report but if in case of urgency, you can use scan based report.

You can refer my blog https://tejas1to4.blogspot.com/2022/10/vulnerability-management-scan-vs-host.html for differences between scan and host based findings.  

Bottom-line is, if you do not find a particular vulnerability in a scan based report, first ensure whether the scan happened properly or not before reaching to any conclusion regarding the vulnerability (don't assume the vulnerability got fixed because you are not seeing it in the scan based report).

Happy Learning !!

Vulnerability Management - Searching with CVE ID

Be careful with Qualys while searching for a particular CVE ID in your environment. Why I am saying so ? .. Let's assume few points to set the context.

Assume the following points: (Feeling like I am studying Mathematics .. "Assume length of rectangle to be x" .. Ha ha :) .. Anyways .. Let's continue)

1. Microsoft published a patch which remediated 'x', 'y' and 'z' vulnerabilities.
2. Your environment is affected with only 'x' vulnerability.
3. The servers are running Microsoft Windows XXXX.
4. Qualys published a QID to check for the patch
5. Qualys published a QID to check for 'x'

Now, with above assumptions in mind, when you check for the exposure status of your environment for 'x', what do you think will happen ?

Well .. You will get many false positives in your search result. Why ? ... Because, now the detection logic is flagging those servers as well which are not vulnerable to 'x'. Again a big WHY ? ... Because the detection logic is looking for the patch and also for the vulnerability itself. You can observe multiple QIDs for that CVE ID. So .. Once you have multiple QIDs, choose the one which is detecting 'x' only and search again.

Sometimes Qualys may take some time to publish the QID which only detects 'x'. So .. In case where QID to detect 'x' is not published, when you search for the CVE ID, you will get only one QID which detects if the patch is installed or not which does not tells you whether your environment is vulnerable to 'x' or not.

Normally, Vulnerability Management(VM) team receives inputs from Threat Intelligence(TI) team and you tend to search using CVE ID and not QID as you are not aware about the related QIDs. 

So just remember, detecting a vulnerability is different from detecting the patch to the vulnerability as the patch might contain fixes to several other vulnerabilities.

Happy Learning !!

Vulnerability Management - Remediation vs Mitigation

Do not use these terms interchangeably !! So .. Let's understand them and see the differences.

Remediating a vulnerability means fixing or eliminating it, dealing with the root cause of the vulnerability. Mitigating a vulnerability, on the other hand, means finding a temporary solution or workaround to decrease the possibility of a vulnerability being exploited.

However, sometimes remediation isn’t possible for several reasons such as the following:

1. A fix, patch or an updated version of the software is not available immediately, since it takes time for the vendors to prepare and distribute them.

2. Not all vulnerabilities need to be fixed. This is usually the case when a vulnerability does not pose a threat since it is not directly accessible or exploitable by a threat actor. For instance, the vulnerable software could be disabled on the Internet connected devices while running only on the not connected devices.

3. Due to managerial issues, you could be hindered from applying a remediation action. This usually happens when a company has strict QoS requirements on customer facing systems and cannot tolerate any downtime required to patch a vulnerability or update a software.

4. Due to some restrictions, such as compatibility issues with other software being used in a system, a fix or patch cannot be applied at all.

Actions to mitigate a vulnerability could be one or some of the following:

1. Blocking a port on a firewall (on a network or host) that could expose a vulnerability to malicious actors.

2. Limiting the use of the vulnerable software to a separated network or a selected list of users.

3. Disabling the vulnerable software temporarily.

Please refer the below URL for more information:

https://cybersophia.net/articles/what-is/vulnerability-mitigation-vs-remediation/#:~:text=To%20sum%20up%2C%20remediation%20is,it%20cannot%20be%20eliminated%20immediately.

Happy Learning !!

Vulnerability Management - Parameters to consider while selecting Vulnerability Management Solution

Following are the parameters one can consider while selecting a scanning vendor:

1. Platform Support 
2. Deployment Options
3. Scanning Method
4. Integration
5. Vulnerability Updates
6. Ticketing/Workflow Integration
7. Detailed Remediation Guidelines
8. Pricing
9. Threat Intelligence Feeds
10. Risk Prioritization
11. Scalability
12. Scheduling Options
13. Technical Support
14. Delivery Model
15. Reporting Options
16. Ease of use
17. False Positive Ration

Please watch the below session by Chintan Gurjar for more details:
https://www.youtube.com/watch?v=UcVflfpZdxI&t=2855s

Happy Learning !!

Vulnerability Management - Compensating controls for unpatched servers

Often due to application dependencies, EOL systems and budget constraints, it is not possible to patch servers. So .. What actions can we take in such situations ? Lookout for answers to the following questions:

1. Is the vulnerability providing information disclosure ? 

Your DLP or WAF solution may already be capable of detecting and mitigating against such an exploit.

2. Does the vulnerability call an application to perform an unwanted action ? 

It is possible that your Host Based Intrusion Detection System can prevent those binaries from executing. 

3. Does the vulnerability require access to a resource or service ? 

An ACL that blocks or restricts access might be the perfect solution.

In case of EOL systems, the following compensating controls can be put in place:

1. Network isolation/segmentation

One option to protect EOL devices is to place critical servers on an isolated network to ensure the devices cannot interact with any machines outside of the isolated network or connect to the Internet. With network isolation, EOL devices are protected from threats, but drastically limit access to other critical assets

including internet and cloud functions. While this security model can be used as a compensating control to mitigate threats, this option may pose business disruption and impact end-user productivity since most server host critical applications that need to be connected to corporate servers for employee access.

2. Virtualization

Hosting assets within a virtualized environment can provide a number of security benefits; increased control over critical assets, ease of re-imaging in the event of a compromise, and the ability to limit critical server exposure to an environment. If an asset becomes a target, it can be quickly isolated and re-initialized. But for critical servers running applications that require round-the-clock access, virtualization represents a possibility of increased administration and resources. It can also lead to failed compliance policies by virtue that in-scope data must be controlled or cannot run within a virtual environment.

3. Application control and whitelisting

It is a security model focused on allowing known “good” applications to run rather than blocking known “bad.” By only allowing trusted software to run, application whitelisting will stop exploits and reduce the administration associated with system and application patching and updates. In “default-deny” mode, application whitelisting is a highly effective compensating control to meet regulatory compliance standards and harden out-of-date systems.

Happy Learning !!

Vulnerability Management - What is a Superseded Patch ?

Ever encountered a situation where your platform team applied a latest patch, still your scanner flagged older patches on that system !! Hang on !! Don't panic. Most probably it is due to a setting "Show missing patches that have been superseded".

A superseded patch is a patch that does not need to be installed because a later patch is available that will correct the same vulnerability.

A typical example is a service pack, which bundles many other patches that have been released before the service pack. If the service pack is installed on a host, earlier patches usually do not need to be installed.

You can choose to enable or disable it in scan policy or report template. When enabled, reports will show previous patches along with the patch which supersedes them. This will help you analyze patch history. You can ask questions to your platform teams like why the server is not receiving regular patches ? Is the server properly onboarded in patching tool ? Is there any connectivity issue between the server and the patching tool ? When disabled, it will directly show you the latest patch which supersedes previous month's patch(s). 

So .. How to determine whether a patch supersedes another one(s) ? Please refer the link https://www.catalog.update.microsoft.com/Home.aspx for Windows OSes.

Also, please refer the below link for more information:

https://tenable.force.com/s/article/Show-missing-patches-that-have-been-superseded-Enabled-vs-Disabled

Happy Learning !!

Vulnerability Management - Is CVE a Vulnerability Database ?

Common Vulnerabilities and Exposures, often known simply as CVE, is a list of publicly disclosed computer system security flaws. CVE is a public resource that is free for download and use. This list helps IT teams prioritize their security efforts, share information, and proactively address areas of exposure or vulnerability.

So .. Is it a Vulnerability Database ?

No, CVE is not a vulnerability database; rather, it’s developed to connect different vulnerability databases and security tools. And because it’s not a vulnerability database, it doesn’t contain information on the risks, the fixes or technical data on the entry.

So .. Which DBs should we consider as a Vulnerability Database ?

1. National Vulnerability Database (NVD)

https://nvd.nist.gov/

2. Vulnerability Assessment Platform (Vulners)

https://vulners.com/

3. Vulnerability Database (VulDB)

https://vuldb.com/

4. CVE Details

http://cvedetails.com/

There are other DBs as well but for time being .. I think these are enough (Ha Ha .. just kidding). Please refer the below link to find more information.

https://securitytrails.com/blog/what-is-cve#top-4-cve-databases

Happy Learning

#vulnerabilitymanagement

CyberSecurity - Few differences which kept me bothering !!

1. Difference between Risk, Threat and Vulnerability

Risk is the potential for loss, damage or destruction of assets or data caused by a cyber threat. Threat is a process that magnifies the likelihood of a negative event, such as the exploit of a vulnerability. And a vulnerability is a weakness in your infrastructure, networks or applications that potentially exposes you to threats.  

https://www.kennasecurity.com/blog/risk-vs-threat-vs-vulnerability/

2. Difference between Vulnerability and Exposure (as the acronym "CVE" contains both)

According to the CVE website, a vulnerability is a mistake in software code that provides an attacker with direct access to a system or network. For example, the vulnerability may allow an attacker to pose as a superuser or system administrator who has full access privileges. An exposure, on the other hand, is defined as a mistake in software code or configuration that provides an attacker with indirect access to a system or network. For example, an exposure may allow an attacker to secretly gather customer information that could be sold.

https://www.techtarget.com/searchsecurity/definition/Common-Vulnerabilities-and-Exposures-CVE

3. Difference between Event, Alert and Incident

A security event refers to the security-impacting activity that occurred. Alerts are the notifications — often found in logs or derived from analysis and a correlation of logs —  a system sends to inform IT and IS teams of the event. Incidents are high-impact security events that have a significant negative impact on a business as a whole and require significant effort to identify, mitigate and remediate. An event may be irregular and/or minor but does not seriously impact a business, or an event could be highly disruptive and possibly cause a loss of revenue, making it an incident.

https://www.deepwatch.com/education-center/what-is-the-difference-between-a-security-incident-an-event-and-an-alert/

4. Difference between Exploit and Payload

Payload refers to the part of malware which performs a malicious action. An exploit (meaning "using something to one’s own advantage") is a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug or vulnerability in order to cause unexpected behavior to occur on computer software, hardware, or something electronic. Such behavior includes things like gaining control of a computer system or a denial-of-service attack.

https://www.ques10.com/p/67205/difference-between-payload-and-exploits-in-syste-1/?#:~:text=Exploits%20give%20you%20the%20ability,like%20denial%20of%20service%20exploits.

Please refer the links above for more information.

Happy Learning !!

Vulnerability Management - How scans work in the background

Phases of a vulnerability scan:

1. Host Discovery

Identify network-accessible systems by pinging or sending them TCP/UDP packets (Scanners will try to probe well known ports to check for responses)

2. Port Discovery

Identify open ports on live systems identified in step 1 (NOT all the 65535 ports are probed!! A Standard Scan includes 1900 TCP and 180 UDP ports by default for Qualys. Typically, the majority of services and listening applications are going to be running on these ports.)

3. Service Discovery

Identify services running on identified open ports in step 2

4. VM/PC Assessment

Gather detailed system information and correlate with known vulnerabilities

Please refer the below links for more information:

https://community.tenable.com/s/article/Phases-of-a-vulnerability-scan

https://qualys.secure.force.com/articles/How_To/000002028

https://www.rapid7.com/fundamentals/vulnerability-management-and-scanning/

Happy Learning !!

CyberSecurity - Why do we need NMAP scripts when we have NMAP switches ?

Let's talk about a tool which is familiar to every CyberSecurity enthusiast ... Yesssss NMAP

One of the ways that NMAP has expanded its functionality is the inclusion of scripts to conduct specialized scans. You simply have to invoke the script and provide any necessary arguments in order to make use of the scripts. The NMAP Scripting Engine (NSE) extends NMAP’s capabilities to enable it to perform a variety of tasks and report the results along with NMAP’s normal output. Some examples of NSE scripts include:

1. Enhanced Network Discovery Perform 'whois' lookups, perform additional protocol queries, and act as a client for the listening service to collect information such as available network shares.

2. Enhanced Version Detection Perform complex version probes and attempt service brute-force cracking.

3. Vulnerability Detection Execute probes to check for specific vulnerabilities.

4. Malware Detection Execute probes to discover Trojan and worm backdoors.

5. Vulnerability Exploitation Execute scripts to exploit a detected vulnerability.

Note:

By default, version scanning (-sV) also executes all NSE scripts in the version category. The -A command-line option executes the -sC command-line option (safe and intrusive categories).

Happy Learning !!

Vulnerability Management - Kenna and RiskIQ

As no. of assets in organizations are growing, vulnerability management solutions have also started gathering overwhelming amount of data(vulnerabilities). And as a result security analysts are coming under pressure to prioritize remediation efforts. Hence tools like Kenna and RiskIQ have started to gain importance.

Kenna uses the following scores to calculate the final asset score: 

Component 1: Vulnerability Scoring

Within Kenna, vulnerabilities from various scanning vendors are brought in during connector runs and normalized based on the CVE ID, CWE ID or the WASC identifier. 

For network vulnerabilities, Kenna will look at the CVSS base score for the CVE. It then look at the 20+ threat and exploit feeds. It has to understand the volume and velocity of attacks against that CVE, if there is malware available, if it is easy to exploit, whether it is actively being exploited in the wild, etc. All of these details help derive the Kenna Vulnerability Score.

Vulnerabilities get a score from 0-100 and are broken out into thirds: Green 0-33, Amber 34-66, Red 67-100

Component 2: Asset Scoring

An asset is as at risk as its highest vulnerability. Hence, it is highest scored vulnerability present on the asset.

Assets get a score from 0-1000 and are broken out into thirds rounded to the nearest 10:Green 0-330, Amber 340-660, Red 670-1000

Component 3: Risk Meter Score

This score is calculated by taking the average of all of the active, non-zero scored assets within the group

Risk Meters can get a score between 0-1000 and are broken out into thirds rounded to the nearest 10: Green 0-330, Amber 340-660, Red 670-1000

Final Asset Score = Highest Vuln Score * Asset Priority (If External IP then raise the score by 200 points)

Please find the below link for more information on scoring methodology:

https://help.kennasecurity.com/hc/en-us/articles/4402070116116-Understanding-Vulnerability-Asset-and-Risk-Meter-Scoring

Please find the below link for more information on asset prioritization methodology:

https://help.kennasecurity.com/hc/en-us/articles/360000862303-Asset-Prioritization-In-Kenna

Happy Learning !!

Vulnerability Management - Network-based vs Agent-based Internal Vulnerability Scanning

Network-based scanning - It is the more traditional approach, running internal network scans on a box known as a scanning ‘appliance’ that sits on your infrastructure (or more recently, on a Virtual Machine in your internal cloud).

Agent-based scanning - It is considered the more modern approach, running ‘agents’ on your devices that report back to a central server.

Following are the parameters on the basis of which one can decide whether to go for Network based or Agent based architecture:

1. Coverage

2. Attribution

3. Discovery

4. Deployment

5. Maintenance

6. Concurrency and scalability

I won't draw any conclusions here as in which type of model is better. It all depends on your analysis based on application of above mentioned parameters to your environment, manpower and budget.   

Happy Learning !!

Vulnerability Management - No. of times detected

If you carefully observe vulnerability reports, you will find one column as detections or no. of times detected. Do not ignore this column.

Now, suppose you run scans on weekly basis. So, in a year, you should run 52 scans. Now, suppose a low priority vulnerability which was out in public in 2022 April. So, from April to October, no. of times the vulnerability is detected should be at least 20(4*5) (excluding April and October month). 

What if the detections are 4/5 times or somewhere near it. Following conclusions can be drawn by the observation:

1. The server on which the vulnerability was detected was offline during the scan

2. There may be intermittent networking issues (Firewall rules or routing issues)

3. One should also check for authentication issues if any

Impact: Due to the above issues, suddenly you can observe age of the vulnerability as 4 or 5 months (because as the vulnerability was detected 4/5 months ago, hence the first detected date would of 4/5 months ago). Now, corresponding platform team would start complaining that the vulnerability didn't appear in subsequent reports and they need time to remediate it as they were not aware of its presence.

Hence, always analyze vulnerability reports carefully so that you can detect such issues in time and take appropriate action on them.  

Happy Learning !!

Vulnerability Management - Stale 'Last Detected' dates

You might have observed stale 'Last Detected' dates in vulnerability report.

Following are the reasons:

1. Authentication not happening properly (Credentials expired or have insufficient privileges)

2. Closed ports

3. Changes made to scan settings (option profile in Qualys)

4. Changes in firewall rules

Because of above reasons, the vulnerability which was discovered earlier, now there is no way to figure out if it exists or not. VM scanning vendors normally choose a false postive rather than a false negative in such a case and decide to keep 'Last Detected' date as when it was actually last detected.

In Qualys, to work around a finding like this, you can adjust the scan option profile being used (or create a new one) with the "Authoritative Option" selected. This make the resulting scan override previous finding and mark them as closed. I would highly caution the usage of this option until clarification on the original finding is clear.

Happy Learning !!