Ostorlab remediation system

This comprehensive guide is tailored to lead you through the essential steps, enabling you to efficiently navigate and leverage Ostorlab remediation system's multifaceted capabilities.

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.

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

Searching

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

Supported keywords are:

• search by priority, values are P0 to P3.

• search by ticked status, values are OPEN, REOPEN, FIXED, FIXED VERIFIED, EXCEPTION and FALSE POSITIVE.

• search by assigned email address or reporter email address.

• search by the boolean shortcut to find tickets assigned to you or reported by you, values are true and false.

• search by tag name and tag value.

• search by creation, modification, starting and ending dates.

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.

To do that navigate to your dashboard and click settings to expand, then choose access.

Click add organisation, and fill in the organisation information.

To add a user, click on the three dots and choose add user option.

And fill the user email.

Also, 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 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.

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 the organisation dashboard.

For a more in-depth understanding of all ticket-related metrics, please refer to the documentation available at the following link.