Remediation

Ostorlab provides remediation capabilities to fix the identified vulnerabilities urgently, diligently, and efficiently. These capabilities are managed through a ticketing system aggregating and pairing all vulnerabilities with a ticket.

The remediation system can either be used as a standalone system or seamlessly integrated with 3rd party ticketing systems like Jira.

The remediation system offers the following capabilities:

• automatically manage the lifecycle of a vulnerability to ensure fixes are verified and enable tracking of their progress
• provide ticket management capabilities to set priorities, assign an owner, and update statuses
• collaborate with team members within the same organisation or by inviting users to your organisation
• set policies to ensure fixes are applied timely and detect missed fixes for tracking and escalations
• collect metrics on the health of your security program and enable a data-backed strategic decision

Ticket Lifecycle

Ostorlab automates the lifecycle of tickets linked to detected vulnerabilities. The ticket lifecycle provides the following capabilities and guarantees:

• A ticket is automatically created in the case of a newly detected security issue. The ticket details contain information about the vulnerability. Priorities are set automatically based on the vulnerability severity.

• The platform will aggregate future occurrences of the same vulnerability in the same ticket. Aggregation is done by ticket detail; for instance, all SQL injections will have a single ticket or an internal attribute called DNA that uniquely identifies each vulnerability. The DNA is computed based on the type of vulnerability to ensure it is uniquely identified.

• Tickets can be marked as fixed.

For fixed tickets, the platform will automatically mark the ticket as verified if the vulnerabilities are indeed absent from future scans.

or will re-open the same ticket.

• Tickets can be marked as an exception or as a false-positive. Excepted and false-positive tickets are kept as is when new occurrences of the same vulnerability are found.

Manually created tickets also benefit from the same ticket management capabilities if a vulnerability is assigned to the ticket.

Ticket Management

A ticket has multiple settings to reflect urgency, priority, ownership, or ease of searching and filtering.

All edits to a ticket are tracked in the activity section to see who did what and when.

Urgency and Priority

The ticket has a priority setting from P0 to P3. P0 is the most urgent, and P3 is the least urgent.

Ownership

A manually created ticket will have a reporter. In addition, you can assign an owner who typically ensures the vulnerabilities are fixed.

You can assign a ticket to an existing user already part of the organisation, or to an external email address. If the email address is not on the platform, it will receive an invitation to join the organisation.

Only an ADMIN can approve the organization's invitation. To do that, you can go to Organisation / Invitation section.

Once the user creates an account and has his invitation approved, he will be automatically assigned the tickets.

Tags

Tickets can have multiple tags assigned. A tag has both a name and a value. Separating of tag names and values enables adding extra meaning to the ticket. For instance, adding an env tag with values like prod, qa, and test, or adding workstream tag with values like featureXYZ.

Setting the value is not obligatory as names only are acceptable.

Searching

The remediation sections offer multiple search capabilities. Searching is done by specifying a supported keyword mapped with the search value.

Supported keywords are:

• priority: search by priority, values are P0 to P3
• status: search by ticked status, values are OPEN, REOPEN, FIXED, FIXED_VERIFIED, EXCEPTION, FALSE_POSITIVE
• assignedEmail: search by assigned email address
• reporterEmail: search by reporter email address
• toMe (boolean): shortcut to find tickets assigned to me, values are true and false
• byMe (boolean): shortcut to find ticket reported by me, values are true and false
• tagName: search by tag name
• tagValue: search by tag value

Collaboration

The remediation offers organisation-wide collaboration. Everything within an organisation is accessible and visible to all members of the same organisation.

This includes scan access, vulnerability data access, ticket data access, etc.

Collaboration on tickets can be done using the comment section; comments can be updated or deleted. A trace of the action is recorded in the activity section.

If you can't share some data across multiple teams, you can create dedicated organisations to confine all interactions within the same organisation. This typically applies when an application is built by an external 3rd party while other applications are built internally.

Policies

One of the five pillars of autonomous security is Policies. There are several policy types, like:

• Patching policy to define when vulnerabilities of different severity are fixed
• Freshness policy to define how outdated are old can be of software or hardware be running on production
• Enforcement policy to define under what conditions can a dangerous system be quarantined or disconnected

These are just samples of remediation policies. At this stage, Ostorlab only supports setting and enforcing the patching policy.

Patching Policy

Patching policy defines SLO (Service Level Objectives) to handle confirmed vulnerabilities and hardening recommendations. An example would be fixing a high severity issue within five days.

The policy is enforced by the ticketing system that compares ticket creation time with the highest vulnerability severity against defined policy.

Metrics and Dashboards

While ticketing helps manage the daily routines and ensure things are fixed and not dropped, they are insufficient to have a holistic look at how a security program is performing.

For this reason, the ticketing system is complemented with a metrics and dashboard pillar, the 5th pillar of autonomous security programs.

The metrics module collects several metrics that are either time based, like count of high severity issues, count of fixed issues and global metrics, like re-open rate, % of secure assets, etc.

These metrics are accessible in an organisation dashboards that have five sections:

Application Summary

The application summary lists the most recent assets and their most recent scan status. This allows a quick look into what has been running and their risk posture.

Maturity Radar

The radar shows the global metrics that score on a scale from 0 to 5. The scores are scales to be comparable with two anchor values. The first is an organisation average collected across all organisation on the platform. The second is a recommended best practice.

The goal is to give a sense to the metrics instead of simply having non-interpretable values.

Vulnerability and Ticket Trending

The trending bars show count of vulnerability counts and ticket updates focusing on confirmed findings and fixed and exception status.

The trending bar is configurable to show any period.

Scan Heatmap

Scan heatmap shows a distribution of scans. This is helpful to ensure that scans are performed regularly, for instance to ensure that there is at least a weekly coverage.

Ticket Calendar

The ticket calendar shows all opened and reopened tickets by time. The tickets marked as fixed, exception, and false-positive are not shown as they should not trigger any action.