Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Scope

This page describes the process and workflow that Deiser follows when a security incident is reported or found.

Departments involved

Deiser DEISER has two departments involved in the resolution of an incident, this is the list ordered by response level:

  1. Support: is the first level of support. Different work shifts are established in order to have 24/7 response. Support employees will resolve the incidents, given they are able to, in the times specified in the SLA agreement.

  2. Development: the second level of support. If an incident cannot be resolved by the Support department, the incident will be assigned to the development department. This department has a deeper knowledge of the system and can change everything in the code even do hotfixes and quick releases.

 

Incidents definition and classification

 

The following table describes the classification of the levels of incidents ordered by priority and the description about them.

 

Severity of the Issue

Description

CVSS v3 Score

Characteristics

Response time SLA

P1

Critical

Critical

Critical Business Impact: Critical issue occurring on production system preventing business operations. A large number of users are prevented from working with no procedural workaround.

  1. System hangs or crashes
  2. Critical functionality not available
  3. Data loss or data corruption
  4. Large number of end users blocked from work
  5. Impact is escalating quickly

1 hour

P2
Major 

 

Significant Business Impact: Major issue occurring on production system severely impacting business. A large number of users are impacted by issue but they are still able to work in a limited capacity.

  1. Significant performance degradation
  2. Important functionality not available
  3. Small number of users blocked from work
  4. Impact is escalating

4 hours

P3
Medium 

Normal Business Impact: Issue causing a partial or non-critical loss of functionality on production system. A small number of users are affected

  1. Some system functions not available
  2. Minor performance degradation
  3. Small number of users impacted
  4. Impact is not escalating

8 hours

P4
Low 

Minimal Business Impact: issue occurring on non-production system or question, comment, feature request, documentation issue or other non-impacting issue.

  1. Incorrect product behavior without impact
  2. Product question or enhancement

 24 hours

 

 >= 9

  • Exploitation of the vulnerability likely results in root-level compromise of servers or infrastructure devices.

  • Exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials or knowledge about individual victims, and does not need to persuade a target user, for example via social engineering, into performing any special functions.

For critical vulnerabilities, is advised that you patch or upgrade as soon as possible, unless you have other mitigating measures in place. For example, a mitigating factor could be if your installation is not accessible from the Internet.

4 hours

High


>=7

  • The vulnerability is difficult to exploit.

  • Exploitation could result in elevated privileges.

  • Exploitation could result in a significant data loss or downtime.

8 hours

Medium 

>=4

  • Vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics.

  • Denial of service vulnerabilities that are difficult to set up.

  • Exploits that require an attacker to reside on the same local network as the victim.

  • Vulnerabilities where exploitation provides only very limited access.

  • Vulnerabilities that require user privileges for successful exploitation. 

24 hours

Low

<4

Vulnerabilities in the low range typically have very little impact on an organisation's business. Exploitation of such vulnerabilities usually requires local or physical system access.

72 hours

Critical and high vulnerabilities:

The way to proceed in order to fix Critical and high vulnerabilities is: 

  1. Identify the exact module on the code that is causing the vulnerability

  2. Fix whatever is necessary on the code

  3. Deploy the solution in a test environment and launch the penetration tests and perform the necessary manual tests to assure the problem is fixed

  4. Deploy an urgent hotfix that will build a new release on Bamboo and will deploy to DigitalOcean the new fixed version in a matter of minutes.


Response times will apply since the date and time when the ticket to Service Desk is opened.

Response workflow

 

The diagram below depicts the workflow that Deiser uses for the resolution of an incident, explained by phases:

Image Removed

 

The categories of the issues created on Deiser’s Service Desk are:

 

...

Category

...

Description

...

Bug

...

A software’s malfunction that cause an error on the system or a wrong behavior.

...

Improvement

...

A suggestion to improve the plugin or one of its features.

...

New Feature

...

A request for new features

...

Question

...

Non-critical vulnerabilities

When a security issue of a High, Medium or Low severity is discovered, DEISER will include the fix in the next scheduled maintenance release.

You should upgrade your installation in order to fix the vulnerability.