Friday, November 25, 2022

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 !!

Tuesday, November 22, 2022

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 !!

Saturday, November 19, 2022

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 !!

Saturday, November 12, 2022

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 !!

Wednesday, November 9, 2022

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 !!

Monday, November 7, 2022

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 !!

Wednesday, November 2, 2022

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 !!

Tuesday, November 1, 2022

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 - 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 t...