This article defines the general Operating Procedures involved in working with the Footprint Platform.

For a detailed first-time service setup please refer to the article here. For the remainder of this article, it is considered that the initial setup of the continuous risk scanning is already performed and the scan surface is configured.

CODA Footprint offers state-of-the-art detection capabilities while optimising compute resources and scan complexity. Eliminate complicated scan schedules, manual scan tinkering, and the tedious task of integrating results from multiple scan engines by using Footprint.

Definitions:

 

Vulnerability Management Lifecycle

Reference: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final

Risk Response Approaches for Software Vulnerabilities

Each known Software Vulnerability has an associated risk. There are four possible risk responses:

1. Accept - Accept the risk associated with the software vulnerability either by determining that the impact is low or by relying on existing security controls to prevent its exploitation. No additional action is needed

2. Mitigate - Reduce the risk by patching, disabling the vulnerable feature, or upgrading to a newer version of the software. Mitigation can also be done by using additional security controls such as firewalls, network segmentation, or virtual patching

3. Transfer - Share the risk or some of its consequences with a third party either by purchasing cyber insurance or by replacing the software with a SaaS offering

4. Avoid - Eliminate the attack surface by uninstalling the software, decommissioning the vulnerable asset, or by disabling the vulnerable features to remove exploitability.

Vulnerabilities may be present in software without it being publicly known but the risk does usually increase once a vulnerability becomes public as attackers are more likely to develop exploits that target it.

The safest response to a Vulnerability is to Avoid or Mitigate the risk as soon as possible but this may sometimes impact functionality.

Software Vulnerability Management Life Cycle

Perform Continuous Scanning to detect new Vulnerabilities.

Choose a use case

Coda Footprint brings together both Red Team and Blue Team tasks in a single integrated platform.

[A] Coda Footprint for the Red Team

Attack surface mapping and detailed vulnerability detection.

List of Activities

1. Define Scan Surface

2. Verify Scan was performed

3. Export Findings

   1. Export CVR Report

   2. Export Cyber Risk Report

   3. Export Technical Report

   4. Export CRSS Report

4. Continuous Monitoring / Clear data

[1] Define Scan Surface

The Scan Surface is composed of Agentless and Agent-Based scans.

Agentless - Network-based scan that performs asset discovery using ICMP and port scans. Runs advanced scanner that would detect software vulnerabilities and other misconfigurations. This type of scan runs over IP, TCP, and UDP and needs network access between the scanner and the scan target. This is a black box scan (unless configured as an authenticated scan).

Agent-Based - locally deployed agent, there is no asset discovery as the agent has to be installed (may perform discovery for AD joined devices if installed as AD-integrated). This is a white-box scan that has detailed information on all the installed Applications.

Agentless and Agent-Based scans are complements meaning that they offer two different points of view on the same device but with different information (that can overlap to some extent for applications that listen on open ports). You may however perform the scan using either one or both. Using both will generate two devices/assets for the same IP address to account for posturing (network scan and local scan).

To define the Scan Surface please browse to your tenant and Select Scan Surface > Agentless Scan Surface > Add elements to scan surface. Insert a list of IP addresses, hostnames, or ranges, pick a Scanner from the bottom drop-down, and click scan.

To define the Agent-Based scan surface please browse to Agent-Based scan surface and deploy a Windows or Mac Footprint agent following the instructions in the portal. Once the agent is deployed it will start sending data within a few minutes. Deploy an agent locally to each computer that you wish scanned or deploy a single AD-integrated agent and allow it to discover AD joined computers on its own.

Example Scan Surface:

Agentless - Correct entries are defined by having a Target configured, at least one IP address scanned as part of the Current Targets, and at least 1 Device (with 1 Application) on the rightmost column.

Agent-based - At least one agent (normally all computers that should be in scope) is configured and is sending data. The Last Update time should be close to the current day and time (less than 24 hours).

[2] Verify Scan was performed

For agentless scans go to Scan Surface > Agentless Scan Surface > Deployed Scanners and check the status of the scanners. It should show as Online and no warning messages are supposed to appear. Also, check that the Last Update time is within the timeframe configured as Scan Frequency (continuous scanning means a scan should occur every 24 hours there should always be a Last Update time that is more recent).

For agent-based scans go to Scan Surface > Agent Based Scan Surface > Deployed Agents and check that the Last Update time is lower than 24 hours before the current time. Agent-based scans are always performed daily regardless of the scheduler.

The universal test is to Browse to Devices and check the latest scanned assets. They are ordered from the top left by their Last Scanned date. If this date is within the configured scan frequency timeframe then scans are happening. Also, check that the devices appear as “Scanned” and not just “Discovered”.

Example:

Once Scan data is coming in kindly allow at least 48 hours from the initial Scan Surface changes to make sure that all the Scan Engines have had time to run at least once and update the data on the device. Normally when adding a new device to the scan surface a Critical Port discovery is performed and then an Advanced Scan is kicked off. This may take up to 15 minutes but for the complete data, you would also need a Full Port scan to run which may take a few hours, and an additional scheduled run of the Advanced Scanner. Usually, 48 hours is a safe time to make sure that the scans have complete up-to-date data.

Review the results by filtering for Critical Status in the Applications tab and browsing the entries marked as red. Check the CVE tab. Now is a good time to mark any possible False Positives (scan errors) in order to prevent them from being presented in the reports.

[3] Export Findings

The consolidated information from the platform scans, both agent-based and agentless, is presented in the Reporting tab. There are many reports but the most relevant are described below.

[3.a] Export the CVR Report

Browse to Reports > Overview > Customer Vulnerability Report and click “Download PDF”.
This report contains the entire tenant level summary of findings and is relevant to C-level staff.

It can help provide an overview of the possible impact of our findings and also a simple interface that shows top findings for this tenant and its contexts. There is also a remediation tracking view that shows how many findings have been fixed and how many are still Active.

[3.b] Export the Cyber Risk Report Summary

This report contains a two page overview of current tenant findings such as total vulnerability counts and top remediation actions. This is relevant when approaching new customers in order to show that detections are present but without going into details. It is also relevant to check detection progress at a glimpse.

 

[3.c] Export Technical Report

The Technical Report contains the complete list of findings. It is found in Reports > Vulnerability > Technical Report. This needs to be exported by pressing “Download as XSLX”. Can be shared with customers on a weekly or monthly basis. If the scan is done one time then it can be exported at the end of the scan engagement having at least 48 hours between Scan Definition and export to allow for all the engines to run properly.

 

[3.d] Export Contextual Risk Report (CRR Report)

CRSS or Contextual Risk Scoring System compares each finding against each other and their configured Contextual Information in order to assess what is the real criticality rating based on asset exposure, vulnerability severity, exploitability, and asset importance. This step is always applied and new findings would always be compared to existing ones so that all findings would always be re-arranged according to their CRSS. This report would help prioritize the most important findings in order to proceed with a risk-based remediation plan.

CRSS Report and Remediation Report. They are found in Reports > Risk > Contextual Risk Report

This report can be exported after the scan or weekly/monthly and sent to the customer.

 

[4] Continuous Monitoring / Clear data

 

For Continuous monitoring the reporting and scan review actions need to be performed on a recurring schedule every week or month before processing and sending reports. Also, reports can be compared to show progress by keeping the older versions saved in a repository/folder outside of the Footprint Platform.

[B] Coda Footprint for the Blue Team

Continuous monitoring and prioritized remediation tracking.

List of Activities

1. Define Scan Surface

2. Verify Scan was performed

3. Evaluate Remediation and Prioritize Critical Findings

4. Execute risk response (mitigation, avoidance)

5. Continue Monitoring

 

[1] Define Scan Surface

The Scan Surface is composed of Agentless and Agent-Based scans.

Agentless - Network based scan that performs asset discovery using ICMP and port-scans. Runs advanced scanner that would detect software vulnerabilities and other misconfigurations. This type of scans runs over IP, TCP and UDP and needs network access between the scanner and the scan target. This is a black box scan (unless configured as an authenticated scan).

Agent-Based - locally deployed agent, there is no asset discovery as the agent has to be installed (may perform discovery for AD joined devices if installed as AD-integrated). This is a white-box scan that has detailed information on all the installed Applications.

Agentless and Agent-Based scans are complements meaning that they offer two different points of view on the same device but with different information (that can overlap to some extent for applications that listen on open ports). You may however perform the scan using either one or both. Using both will generate two devices/assets for the same IP address to account for posturing (network scan and local scan).

To define the Scan Surface please browse to your tenant and Select Scan Surface > Agentless Scan Surface > Add elements to scan surface. Insert a list of IP addresses, hostnames, or ranges, pick a Scanner from the bottom drop-down and click scan.

To define the Agent Based scan surface please browse to Agent-Based scan surface and deploy a Windows or Mac Footprint agent following the instructions in the portal. Once the agent is deployed it will start sending data within a few minutes. Deploy an agent locally to each computer that you wish scanned or deploy a single AD-integrated agent and allow it to discover AD joined computers on it’s own.

Example Scan Surface:

Agentless - Correct entries are defined by having a Target configured, at least one IP address scanned as part of the Current Targets and at least 1 Device (with 1 Application) on the rightmost column.

Agent-based - At least one agent (normally all computers that should be in scope) are configured and are sending data. The Last Update time should be close to the current day and time (less than 24 hours).

[2] Verify Scan was performed

For agentless scans go to Scan Surface > Agentless Scan Surface > Deployed Scanners and check the status of the scanners. It should show as Online and no warning messages are supposed to appear. Also check that the Last Update time is within the timeframe configured as Scan Frequency (continuous scanning means a scan should occur every 24 hours there should always be a Last Update time that is more recent).

For agent based scans go to Scan Surface > Agent Based Scan Surface > Deployed Agents and check that the Last Update time is lower than 24 hours before the current time. Agent based scans are always performed daily regardless of the scheduler.

The universal test is to Browse to Devices and check the latest scanned assets. They are ordered from top left by their Last Scanned date. If this date is within the configured scan frequency timeframe then scans are happening. Also check that the devices appear as “Scanned” and not just “Discovered”.

Example:

Once Scan data is coming in kindly allow at least 48 hours from the initial Scan Surface changes to make sure that all the Scan Engines have had time to run at least once and update the data on the device. Normally when adding a new device to the scan surface a Critical Port discovery is performed and then an Advanced Scan is kicked off. This may take up to 15 minutes but for the complete data you would also need a Full Port scan to run that may take a few hours and an additional scheduled run of the Advanced Scanner. Usually 48 hours is a safe time to make sure that the scans have the complete up-to-date data.

Review the results by filtering for Critical Status in the Applications tab and browsing the entries marked as red. Check the CVE tab. Now is a good time to mark any possible False Positives (scan errors) in order to prevent them from being presented in the reports.

[3] Evaluate Remediation and Prioritize Critical Findings

 

There are Two Reports that show Risk Prioritization in real-time.

CRSS Report and Remediation Report. They are found in Reports > Risk > Contextual Risk Report and Reports > Remediation > Remediation report

The two reports need to be exported by using “Download to XLSX” and forwarded to the end-customer on a weekly/monthly basis.

A remediation plan needs to be prepared and agreed in order to fix all the findings and reduce the customer’s organization risk. More details are provided on the following step.

 

[4] Execute risk response (mitigation, avoidance)

When working with Footprint from a Blue Team perspective the focus is on Remediation or removal of existing vulnerabilities. Possible remediation actions are:

Mitigate - Reduce the risk by patching, disabling the vulnerable feature or upgrading to a newer version of the software. Mitigation can also be done by using additional security controls such as firewalls, network segmentation or virtual patching

Avoid - Eliminate the attack surface by uninstalling the software, decommissioning the vulnerable asset or by disabling the vulnerable features to remove exploitability.

 

Remediation is approached by either exporting the Remediation Report and sending it to the IT Administrator or owner of the asset/application in order to apply or schedule application of a patch/upgrade or by doing “per finding” remediation where you would go to Devices > Associated CVE’s

For Option [1] export the Remediation Report and send it to the asset/application Owner you need to browse to Reports > Remediation > Remediation report and press “Download as XSLX”. Then send the file to the appropriate team for fixing the issue or to the end customer. Usually remediating the top 10 findings each time the report is exported (weekly / monthly) would drastically reduce the organization exposure of the scanned attack surface because Remediation entries are always sorted by their total cumulative risk value (CRSS).

In this example we can compare the first four finding's cumulated CRSS to the fifth finding’s CRSS and notice that the difference is very high. Therefore we can keep Remediating the first page of the Remediation Report if there are low resources to perform patch deployment or continue to the following pages if we have more manpower available to perform the fixes.

Ideally You would always want to prioritize to solve the most quantitative remediations (such as First Page Remediation Report or Top 10 Remediation Report entries) and the most qualitative findings that are found in the CRSS Report (Reports > Risk > Contextual Risk Report).

Therefore we need to take a balanced approach where we address both top findings in the two reports.

The Footprint Platform offers tools to address prioritization and planning. You may take the findings and send them to the “Review” shortlist.

This would take any Vulnerability and add it to Reports > Risk > In Review Report. This can be shared with application owners or with other users of the Footprint Platform to take action on the shortlisted findings.

Other options on the Vulnerability level are to “Mark as False Positive” or “Accept Risk”. Those are both actions that would mark the findings as known and stop them from showing up in any reports.

Ideally, all the Critical, High, and Medium findings should be categorized as “Fix Confirmed”, “False Positive” or “Accepted Risk” in order to reduce the Organizational Exposure to the minimum. This would mean that in the Devices or Applications we are striving to obtain an all “green” or “Secure” status.

This cannot always be achieved as new vulnerabilities are always published and subsequent scans would show new findings

To see which items need to be remediated you need to view the Remediation Report found in Reports > Remediation > Remediation report

The Remediation report shows what patches need to be applied or what updates/upgrades to existing software versions have to be implemented. There is always an option to remove an application and this would also fix the finding by avoiding the risk completely.

Remediation entries are grouped by remediation action and each similar action has an expandable list of devices that it affects. Once a Remediation action (patch, upgrade, remove) is applied outside the Footprint platform those Remediation entries disappear. To check that a finding is fixed it has to be in a “Fix Confirmed” state.

 

[5] Ongoing Monitoring

 

Continuous monitoring is one of the main advantages of the Footprint solution. Scans are performed as often as possible in order to keep the chosen scan frequency but also accommodate the size of the scan surface. This way of monitoring allows for agile detection of new vulnerabilities or changes in the scan surface while also optimizing compute resources and eliminating scan scheduling complexity.

Even if at the current scan time there are no vulnerabilities reported as new ones are published the scan engine is updated and existing Secure applications may become vulnerable. This means that on each new scan, new findings may appear even if Application versions are not changed.

Scans are ideally performed daily but to have a good compromise between productivity and security it is possible to schedule scans weekly or monthly. For example, a good scan time is always after Microsoft Patch Tuesday.