Vulnerability Management - Interview Questions

Most of the questions are straightforward. You can google 90% of the questions. 

Happy Learning !!

Vulnerability Management - SCAP and DISA STIG

As free versions of commercial vulnerability management vendors do not provide compliance scanning options, we can use freely available tools such as SCC (DISA) and CAT Lite (CIS) from learning perspective.

I have created a document depicting the use of SCC from DISA. You can google basic concepts such as CIS, DISA, STIG, SRG, CIS Benchmarks, SCAP, OVAL, CVE, CPE, XCCDF, CCE and OCIL etc.

I find Wikipedia definition perfect, "SCAP comprises a number of open standards that are widely used to enumerate software flaws and configuration issues related to security. Applications which conduct security monitoring use the standards when measuring systems to find vulnerabilities, and offer methods to score those findings in order to evaluate the possible impact. The SCAP suite of specifications standardize the nomenclature and formats used by these automated vulnerability management, measurement, and policy compliance products.

A vendor of a computer system configuration scanner can get their product validated against SCAP, demonstrating that it will interoperate with other scanners and express the scan results in a standardized way." 

Point of this post was as free tools, resources and videos are available, let's make use of these and come out of the mindset that we can learn only when we will join some organization. I agree, there is no substitute to industry experience but nobody can stop you from learning. Let's create labs, read documentation, demonstrate PoCs, and share the gained knowledge with community. Thanks to all content creators on YouTube and Linkedin, I have learned a lot from you and I am still learning.

Happy Learning !!

Vulnerability Management - SSL vs TLS

 In one of the interviews, interviewer asked me "What is the difference between SSL and TLS ?"

I said TLS is successor of SSL. But he was not satisfied with my one line answer. Then he asked "Does that mean there is no difference between SSL and TLS ?"

So guys following are the high level differences between SSL and TLS:

1. Hashing --> SSL uses MD5, SHA-1 while TLS uses SHA-256
2. Key exchange algorithm --> SSL uses KEA while TLS uses DH, ECDH, DHE, ECDHE, PSK etc.
3. Data encryption --> SSL uses DES, RC4 etc. while TLS uses AES etc.
4. Integrity --> SSL uses MAC while TLS uses HMAC

The point of this post is, don't be like me, be like Bob.

Whenever Bob studies a concept, he always asks himself WHY ? (For e.g. in this case) "Why TLS is needed when SSL is already there ?"

So, being in cybersecurity domain, you are not always expected to know low level details of each and every protocol but atleast you should know high level details and be able to corelate your answer with vulnerabilities (For e.g. in this case, SSL3.0 is vulnerable to BEAST and POODLE attacks whereas TLS1.0 fixes them).

Happy Learning !!

Vulnerability Management - Secure privileged account use

As performing a vulnerability scan or audit with an account lacking sufficient privileges may result in incomplete result, scanning solutions must be provided with privileged authentication and access levels to access the end system.

Since accounts used are privileged ones, following are the strategies Tenable recommends to avoid any kind of misuse:

1. Implement compensating controls for privileged accounts to limit risk, such as:

a. Log monitoring for when the account is in use outside of standard change control hours, with alerts for activities outside of normal windows.

b. Perform frequent password rotation for privileged accounts more often than the “normal” internal standard.

c. Enable accounts only when the time window for scans is active; disable accounts at other times.

d. On non-Windows systems, do not allow remote root logins. Configure your scans to utilize escalation such as su, sudo, pbrun, .k5login, or dzdo.

e. Use key authentication instead of password authentication.

2. Use Nessus Agents where available.

3. If you do not grant an exception with compensating controls, perform a scan with an account having lower privileges than what Tenable recommends and observe any missing results. Modify the account privileges so that all expected results are shown. Changes to the audit file or plugins may impact results later.

Please refer below URLs for more details:

https://docs.tenable.com/nessus/compliance-checks-reference/Content/CredentialedScanningandPrivilegedAccountUse.htm

Happy Learning !!

Vulnerability Management - On a lighter note !!

Few nessus agents were appearing offline in Nessus Manager. I was working with a Windows engineer to troubleshoot the issue.

Normally, to resolve this issue, we try to unlink and re-link the Nessus Agent, from the Agent host.

As an administrator, from a command prompt, run the following commands:

Based on your operating system, use either C:\Program Files\Tenable\Nessus Agent or C:\ProgramData\Tenable\Nessus Agent.

> net stop "Tenable Nessus Agent"

> "C:\Program Files\Tenable\Nessus Agent\nessuscli" agent unlink (--force)

> "C:\Program Files\Tenable\Nessus Agent\nessuscli" agent link --key=<key> --host=<host> --port=<port>

> net start "Tenable Nessus Agent"

I shared the steps with the engineer and asked him to execute them. While he was running those commands, suddenly he asked me, if we are stopping the "Tenable Nessus Agent" service then what is the use of running subsequent commands ? I went blank for a couple of minutes.

Happy Learning !!

Vulnerability Management - Duplicate entries in vulnerability database

 Let's first understand what a reimage is ->

A reimage is the process of installing a new operating system on a machine. This process includes wiping, or clearing, the hard drive entirely, and installing a fresh operating system. When the reimage is complete, it is almost like getting a brand new machine!

Now, both Qualys and Tenable stamp a machine with a tracking UUID the first time they scan it. This way, if a machine changes IP addresses, or has multiple network interfaces, they can track the machine without creating duplicates.

But when you reimage a machine, Identification Attributes change, which in turn means same vulnerability will be repeated. How ? Suppose a developer is using a particular version of a library. This particular version is affected with a vulnerability. The developer after working for few days decides to move out of the organization. The machine is sent to reimage. Now, another developer gets this machine. When Tenable agent is installed, it creates a new UUID. If the new developer installs and uses the same library then a duplicate entry will be created.

As the machine was using the same mac address and hostname, for the particular instance (Hostname + Port + Vulnerability), there will be two entries (two UUIDs). Tenable considered the machine as two different machines. Hence solution to such issue is:

Save the whole key before you rebuild the machine, then restore the key before you re-scan it, or before you install the Qualys/Tenable agent if you use agents (Qualys stores its UUID in the Registry, in HKLM\Software\Qualys, Tenable stores its UUID in HKLM\Software\Tenable).

Please refer below URLs for more details:

https://dfarq.homeip.net/rebuild-machines-without-making-duplicates-in-qualys-or-tenable/#ixzz86yZsaJIb

https://community.tenable.com/s/article/How-Does-Tenable-io-Identify-an-Asset-as-Unique

https://hub.wpi.edu/article/183/prepare-a-computer-for-reimage

For duplication, there are other use cases also. This is just one of the use case.

Happy Learning !!

Vulnerability Management - Scanning using Nessus Essentials

Prepared a document on scanning a Windows 10 workstation using Nessus Essentials. It is a free version of Nessus vulnerability scanner hence you cannot perform compliance checks. However, purpose of creating the document was to let you know how you can scan your workstation successfully. Normally, if you enter correct credentials in scan policy, authentication will be successful still the scanner will not be able to gather much data. Certain registry changes are required and few services need to be enabled for a successful scan. 

Downloading and installing Nessus Essentials is good to learn but the main part is about registry changes and services. One should understand why they need to be enabled and their significance.

I have added references to videos and websites I referred in the document.

 

Happy Learning !!

Cybersecurity - Architect vs Engineer vs Analyst

Cybersecurity Architect - One who decides how security is done and has holistic view of an organization's architecture (Expert in multiple domains)

For e.g. One who knows where firewall, AV, SIEM, VM, IDS/IPS, proxy, DLP etc. should be placed. Decides what policies should govern operation of aforementioned tools.

--> More involved in decision making

Cybersecurity Engineer - One who follows a given design and builds/engineers solutions.

For e.g. One who actually deploys and maintains (Deploy/Configure/Upgrade/Troubleshoot/Decommission) above mentioned solutions. 

--> More involved in implementation

Cybersecurity Analyst - One who uses data generated by these solutions to ensure cybersecurity. Provides feedback and reports issues to engineers based on which engineers finetune solutions.

For e.g. One who works on dashboards, alerts, incidents, reports etc. generated by above mentioned cybersecurity solutions.

--> More involved in analysis

Each role has its challenges, hence one should not reach to immediate conclusion about betterness of these roles over one another.

 

Happy Learning !!

Vulnerability Management - BAU (Business As Usual) and Ad hoc tasks

Once scanners are deployed, scans are scheduled and, reports are configured, one may ask, then what tasks vulnerability analysts/engineers perform?

So following are the tasks which are operationalized:

1. Authentication - Troubleshoot authentication issues.

2. Scan Coverage - Ensure scope for vulnerability scanning (cloud and on-premise) is defined and you are covering all the systems in scope. This may require co-relation with CMDB.

3. Offline Agents - Ensure the agents which are offline are of systems which are decommissioned. Agents can go offline due to variety of other reasons as well.

4. Reports - Normally, a lot of vulnerabilities are not patched by patching teams such as vulnerabilities related to 3rd party applications. They will patch vulnerabilities related to OS and corresponding native applications. Hence, you will always face requests to transfer ownership of such vulnerabilities. So, you will need to make changes to reports frequently if not regularly. You will also need to analyze reports to find assets which are not patched regularly (You can find out assets which are not onboarded in patching tools). 

5. Policy Fine Tuning - There are vulnerabilities which require particular settings to detect them. Similarly, for compliance, there are controls which require modifications depending on the environment.

6. Managing False +ves and Exceptions - As scanning solutions have limitations hence, false +ves and exceptions will generate.

7. Rescan and Decommission requests - These tasks are performed on regular basis.

8. Weekly/Monthly calls with various stakeholders - Normally, current status of remediation efforts and challenges faced by application/platform teams are discussed.

9. Penetration and Audit findings - You will need to work with various teams to fix these findings.

10. VM Policy - Every organization has a policy where SLAs and critical assets are defined. You will need to create/fine tune such policies.

11. Deliver Trainings - As attack surface is ever evolving, you will need to give regular trainings on cybersecurity best practices (Phishing/Shift left approach/Safe browsing etc.).

12. Sync with TI - Be in sync with Threat Intelligence team and prioritize remediation according to their inputs.

Following are the tasks which are done on Ad hoc basis:

1. Scanner/Manager upgrade.

2. Troubleshoot connectivity issues between scanner and manager or agents and manager.

3. Deploy new scanner/manager

4. Integration with various tools such as the following:

• ITSM (e.g. ServiceNow)   
• CMDB (e.g. ManageEngine)
• Risk Assessment (e.g. Kenna)

5. Task automation (e.g. Scripting using Python or VB)

 

Happy Learning !!

Vulnerability Management - Paranoid Mode

In Tenable, detection of few plugins require paranoid mode to be enabled.

It allows a user to specify whether or not we should only report vulnerabilities with a high level of confidence, or be a little more paranoid and flag a system if there is possibility they are or could be vulnerable. It can lead to potential false positives but can give a larger view of their cyber exposure.

Generally, when paranoid mode is enabled, number of vulnerabilities detected will increase. Following are the few reasons:

1. Backported patches are ignored: When applications are backported by package maintainers, the version displayed when installing through a package manager may differ than a package downloaded directly from a vendor. When Paranoid Mode is enabled, backported patches will not be considered, resulting in a false positive for the 'missing' patch.

2. Some plugins (depending on how the detection is performed) may only have version information to work with, and not specific configuration information about the host. Often a vulnerability may only exist if a specific configuration is enabled and if the plugin cannot gather this info, paranoid mode is used. A common example of this is Cisco configurations noted in their advisories. In these instances you may see a false positive.

3. When a plugin is performing a direct check against a host, such as directly exploiting a certain vulnerability, this could lead to potential false positives due to the nature of the vulnerability. For example if we have to rely on an HTTP response header to determine if an exploit was successful, this could lead to a false positive for an unaffected device, or an IDS/IPS/Firewall could alter the response.

Please refer below URLs for more details:

https://community.tenable.com/s/article/How-to-know-when-a-plugin-is-made-paranoid

https://community.tenable.com/s/article/Which-plugins-require-the-paranoia-setting

https://community.tenable.com/s/article/How-does-Show-potential-false-alarms-impact-a-scan-scanning-in-paranoid-mode

Happy Learning !!

Vulnerability Management - Analyze before upgrading versions

Microsoft released a security update for .NET core on December 2022. Tenable also released a signature to detect the update (Plugin ID 168747 https://www.tenable.com/plugins/nessus/168747). Solution was, "Update .NET Core Runtime to version 3.1.32 or 6.0.12 or 7.0.1." Now, if you carefully go through Microsoft's support policy (https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core), you can observe, version 3.1.32 became EoL on December 13th 2022.

If you are below 3.1.32, then obviously the statement "Update .NET Core Runtime to version 3.1.32 or 6.0.12 or 7.0.1." makes sense. But, if you apply the security update to mitigate one detection, another detection of 3.1.32 being EoL will follow you soon. Tenable released a signature to detect .NET core EoL versions on 7th March 2023 (https://www.tenable.com/plugins/nessus/172177).

As a patch analyst, you should not say, I brought old versions of .NET Core to 3.1.32 with huge effort and now you are telling that 3.1.32 became EoL. Please remember, scanning vendors, will not report multiple solutions in one finding. If a version misses a security update, it is a separate finding than the version itself becoming EoL, and hence solutions will also be different. So, one has to be aware of product lifecycle before applying patches.   

So, before updating a software, please check, when the version of the software to which you want to update, is going to become EoL. If it is going to become EoL in coming 2-4 months, you might want to go for major upgrade.

Happy Learning !!

Vulnerability Management - To be or not to be (A false positive)

I wanted to discuss a situation where you clueless !!

VMware released an advisory consisting security updates for vulnerabilities @CVE-2022-31696 and CVE-2022-31699 (https://www.vmware.com/security/advisories/VMSA-2022-0030.html).

Now, Tenable published a signature to detect the vulnerability @168828 (https://www.tenable.com/plugins/nessus/168828).

If you check response matrix for CVE-2022-31696 for ESXi 7.0 in VMware's advisory, it says, fixed version is ESXi70U3si-20841705 ("05"). If you click on the link, it will take you to ESXi 7.0 release notes (https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3i-release-notes.html). Now if you scroll down a bit, you can see the download is for ESXi70U3si-20841708 ("08"). The difference between two versions i.e. "05" and "08", is of component and driver updates. "05" has security updates only while "08" has security, component and driver updates. I observed, in few cases, due to hardware dependencies, support teams are not able to upgrade to "08". But, Tenable is detecting "05" version as vulnerable. Since "05" already has security updates, support teams are claiming this detection as false positive.

Now, in counter, Tenable is saying, when go from VMware's advisory to release notes, the download file is for "08". So this is not a false positive. Either there is a typo from VMware or "08" is the correct build.

So yes, if you understood the scenario, such cases also occur. Our support team has reached out to VMware already but not sure how much time VMware will take to address this issue.  

Not sure what VMware and Tenable will do, in the interim we are trying to make peace with the support team (ha ha).

Happy Learning !!

Vulnerability Management - Tenable.sc First Discovered Date Fluctuating

Some common environmental factors which will cause the first discovered dates to fluctuate are:

1. Targeting a system by FQDN or hostname when that name could resolve to multiple IPs. Two common examples of this are a system that is behind a load balancer or a system that has multiple NICs. Customers should be working with their network and/or DNS admins to determine if this is a possibility for the primary DNS server used by Tenable.sc, which can be found in /etc/resolv.conf.

2. Assigning systems a new IP address via DHCP when the dhcpTracking setting is not uniform across all scans for the organization.

3. Assigning the same IP to multiple systems in different networks and importing the scan results into the same repository. If 172.26.0.1 in network A is a different system than 172.26.0.1 in network B and each are scanned, Tenable.sc will consider them one system and the vulnerability data may not appear accurate due to the differences in the target systems. Customers should be working with their network and/or DNS admins to determine if this is a possibility in the environment.

4. Deploying virtual systems from the same template / image without adjusting the underlying network settings. Any duplication of FQDN, MAC, or NetBIOS across different systems will prevent Tenable.sc from uniquely identifying them, causing all the vulnerability data to collide under the same IP.

Please refer below URL on how one can normalize this behavior:

https://community.tenable.com/s/article/Tenable-sc-First-Discovered-Date-Fluctuating

Happy Learning !!

Vulnerability Management - Scan with low privileged service account

Recently encountered a situation where few false positives appeared on some Cisco devices. Whenever false positives appear, first thing to check is authentication. If it is happening properly then you should go for authorization check.

Now in this case, scan happened with privilege level 1. After investigation, we found that, the service account in use was part of multiple AD groups (ISE is integrated with AD). This created a conflict in privilege level and low privilege was chosen. This in turn resulted in false positives on some Cisco devices.

Hence always ensure, the service accounts dedicated for vulnerability scanning should not be part of any irrelevant groups.

Happy Learning !!

Vulnerability Management - Detection based on application's self-reported version number

Let's understand one use case. 

Apache published a new version of HTTP server i.e. v2.4.55 (https://httpd.apache.org/download.cgi). Now, if you check the version of Apache HTTP servers which are shipped with Redhat, you would find upstream versions are on or below v2.4.53 (https://access.redhat.com/solutions/445713).

Now, Tenable started detecting versions 2.4.x < 2.4.55 as vulnerable to CVE-2006-20001, CVE-2022-36760, CVE-2022-37436 (https://www.tenable.com/plugins/nessus/170113). But these web servers are only vulnerable when "mod_proxy_ajp" module is in use. Solution to this vulnerability is to disable the module (https://access.redhat.com/security/cve/cve-2022-36760). However, even after disabling the module, Tenable will continue to flag the vulnerability as it is not checking whether the module is in use or not.

You can use the command "apache2ctl -M" to check for loaded modules of Apache in Linux systems (https://www.tecmint.com/check-apache-modules-enabled/).

Hence, from my perspective you have the following options:

1. Recast the risk of the vulnerability from "Critical" to "Medium"/"Low" so that it doesn't get counted in any KPI metric

2. Provide temporary exception for 4 or 6 months

So, whenever you come across detections based on application's self-reported version number, be vigilant and perform proper vulnerability analysis.

Happy Learning !!

Vulnerability Management - Skipping scheduled daily agent scans

Many organizations have employees working in shifts. Hence, while running agent based scans, it becomes important to manage coverage of all in scope workstations. Normally, to cover them, scan window is set to 24 hours.

But because of this scan window, scheduled daily agent scans will be skipping. Since the scan will start a few minutes later than scheduled there is a chance that the next scheduled daily scan will not start because the previously scheduled occurrence is still running.

Solution to this issue is to change scan window to 1380 minutes (23 hours). This gives some padding for post processing to complete before the next scan launches avoiding overlapping of scan jobs which results to scheduled scans skipping.

Happy Learning !!

Threat Intelligence vs Threat Hunting vs Threat Modeling

Threat Intelligence -> Data that is collected, processed, and analyzed to understand a threat actor’s motives, targets, and attack behaviors.

Threat Hunting -> Process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions.

Threat Modeling -> Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.

Please refer the below links for more information:

https://www.crowdstrike.com/cybersecurity-101/threat-intelligence/

https://owasp.org/www-community/Threat_Modeling

Happy Learning !!

Vulnerability Management - Nessus Knowledgebase

A Knowledgebase (KB) is created for each target during a Nessus scan. When a plugin collects information that needs to be "shared" with other plugins it is stored in the KB for that host. The KB can be found for a specific host in the Host Details section of the scan results reached by drilling down on that host.

Note: Nessus also collects a global KB that shares information not only between different scripts but between different hosts.

KBs are in the following format:

timestamp data_type key=value

-> timestamp: Epoch time representing when a scan completes

-> data_type: 1 is for strings, 3 is for integers

For e.g. 1475164035 3 portscanner/14272/Ports/tcp/1334=1

There are several functions used by plugins to read or write information to the KB:

1. set_kb_item(): Adds a new item in the host knowledge base. The value can either be a string or an integer. If an item with the same name already exists in the KB, it's unaffected as the KB can have the same key listed multiple times.

2. set_global_kb_item(): Adds a new item in the global knowledge base. The value can either be a string or an integer. If an item with the same name already exists in the KB, it's unaffected as the KB can have the same key listed multiple times.

3. replace_kb_item(): Same as set_kb_item() except it will replace the value found in the key.

4. get_kb_item(): Fetches the value of the key in the KB (all of them if more than one exists) and returns the result.

5. get_global_kb_item(): Fetches the value of the key in the global KB (only the first value if more than one exists) and returns the result.

6. rm_kb_item(): Deletes a KB entry. If multiple entries exist, specifying a value makes the function only delete the entry for that specific value.

7. get_kb_list(): Returns the list of values for KB keys matching a certain pattern (e.g. "SMB/Registry/*")

8. get_global_kb_list(): Same as get_kb_list but for the global KB.

Please refer the below link for more information:

https://community.tenable.com/s/article/What-is-the-Nessus-Knowledgebase-KB

Happy Learning !!

 

Vulnerability Management - Firewall Detection

NMAP has several techniques for firewall detection. Since enterprise networks have large subnets, it is not practical to employ such advanced techniques for scanning an environment with 10000+ assets.

Below is a general method used by Qualys.

When there is no firewall between a scanner and a target host, all TCP packets sent by the scanner to the target host should trigger a reply packet from the target host. When there is a firewall, this is no longer true. There are two general firewall behaviors that Qualys relies on for this detection:

-> No reply (silently dropped)

-> Connection reset (RST)

With regard to the first behavior, some firewalls will drop TCP SYN packets sent to certain ports. In this case, the TCP SYN packets sent by the scanner to these ports will not generate a reply. So when we send SYN packets to the target host and do not receive a reply, we know there is a firewall.

With regard to the second behavior, other firewalls will respond to TCP SYN packets sent to certain ports with RST packets on behalf of the target host. To detect this type of firewall, Qualys analyzes the TTL values of the RST reply packets (from the firewall) and the SYN-ACK packets (from the target host). This method requires that the firewall allows SYN packets to some ports to go through and reach the target hosts while resending SYN packets to other ports on behalf of the target host.

False positives can come when network conditions are bad leading to packets being dropped. You can choose to disable TCP ping method or consider ICMP unreachable messages as a sign of dead host for proxy ARP replies.

Please refer the below links for more information:

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

https://docs.rapid7.com/nexpose/configuring-asset-discovery/#collecting-information-about-discovered-assets

https://community.tenable.com/s/article/Scan-is-returning-results-for-IPs-which-are-known-to-be-dead-or-non-existing

https://nmap.org/book/firewalls.html

https://www.tenable.com/blog/4-ways-to-improve-nessus-scans-through-firewalls  

Happy Learning !!

Vulnerability Management - General best practices for searching a vulnerability

While checking if a vulnerability exists in your environment, take care of the following points:

1. Check if the scanning vendor has published a signature to detect the vulnerability. Sometimes a QID/Plugin ID is mapped to the CVE ID but will be in development phase and is not yet published.
2. Check if authentication is required to detect the vulnerability. For plugin ID, you can check the type (local/remote), and for QID, the discovery method (Remote Only/Authenticated Only/Remote and Authenticated).
3. Sometimes scanning vendors will detect a patch to the vulnerability instead of searching for the vulnerability itself. If the patch is superseded by some other patch which is already installed, then the detection is a false positive.
4. Sometimes a feature of a OS will be vulnerable. Check whether the detection logic is checking the OS version for flagging the vulnerability. If this is the case then you will need to check with platform support teams as in the feature is in use or not.
5. Ensure scan traffic is not obstructed by firewall (Basically, if you are searching a vulnerability in a system(s), ensure the system(s) are getting scanned properly).

The whole point is, do not just enter QID/Plugin ID in filter, hit enter and based on search results decide whether the vulnerability exists or not. If architecture is scanner based, operationalize troubleshooting authentication issues and if it is agent based, offline agent issues.

Happy Learning !!

Vulnerability Management - Tussle with Application team

Qualys has started considering RSA and DHE algorithms with 1024 bits key size as weak (QID 38863). There are a lot of applications which implement their own SSL/TLS libraries. Now, here comes the issue. Windows has its own library for SSL/TLS aka Schannel. When you install a JAVA application on Windows platform, as the application has its own library, making changes at OS level is not enough.

Whenever you find QID 38863 detected on a Windows platform, take the following actions:

1. Identify the port on which QID is flagged
2. Run the command -> netstat -ano | findStr "2216"
3. Check the process ID of the process using that port 
4. Open task manager and check for the name of the process or run the command -> tasklist /fi "pid eq 2216"

If it is a JAVA application, then you will have to ask the application support team to go through the following links and make necessary changes:

https://docs.oracle.com/en/applications/jd-edwards/administration/9.2.x/eotsc/disabling-weak-cipher-suites-globally-through-java.html#u30144032

https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html

Similarly for .NET application, https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls

Most probably, the application team would not appreciate this as for making any change they will have to take backup, take downtime, perform the change and then ask for a rescan. But as a security analyst you will have to justify as in why disabling weak protocols and cipher suites is important.

For applications which use Windows native SSL/TLS i.e. Schannel, you can make the changes at OS level.

Following are the registry paths which you can refer:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\

HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

Following is the wikipedia page for comparison between various TLS implementations:  

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

Please don't try to search for CVE corresponding to QID 38863 as you won't find one.

Happy Learning !!

Vulnerability Management - Agent Based Scan

 Just in case if you think agent based architecture is the best, get to know about the following points:

1. Agents cannot be installed on IoT and network devices such as routers, switches and firewalls.
2. Agents cannot discover vulnerabilities related to SSL.
3. Agents cannot discover newly added devices as they do not perform discovery scan.

There are other drawbacks as well but then drawbacks also exist in scanner based architectures.

Please refer the below link for lists of Qualys agent versions and their supported platforms:

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

Please refer the below link for lists of Nessus agent versions and their supported platforms:

https://docs.tenable.com/generalrequirements/Content/NessusAgentSoftwareRequirements.htm

Happy Learning !!

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