Service Level Objectives

Service Level Objectives (SLOs)

 

 

• Response time is measured from the successful receipt of an alert into the TENEX.AI Platform.
• Critical resources will be scoped and mutually agreed upon during onboarding, or alternatively heuristically determined by the Tenex Platform.

 

Severity Definitions 

Severity is established by a combination of event criticality and system criticality as defined in the tables and definitions below.

 

Event Criticality

 

Low – Events or detections that do not denote a significant compromise of data, systems, or operations (e.g. events denoting misconfiguration of resources, potentially unwanted applications (PuPs)) and events from detections with high false positive rates. These typically require investigation and potential corrective action for hygiene or preventative purposes but are not time critical. This includes requests generated manually by the Client (e.g. submitted ticket to [email protected] for general questions or inquiries) which are not explicitly defined at the time of request as an escalated Severity 2 or Severity 1.

 

Medium – Events or detections suggesting a non-immediate threat or security risk but could escalate if they are not addressed. (e.g. brute force password attacks, internal network scanning, trending vulnerability scans against internet-facing resources). Such events or detections must have low false positive rates.

 

High – Events or detections indicating imminent service disruption or data compromise (e.g. unblocked malware, successful DoS/DDoS attacks).  Such events have extremely low false positive rates.

 

Entity Criticality

 

Low refers to the majority of systems, users, or groups in a client’s organization. These typically include: standard employee workstations, peripheral devices, dev/test systems, and internal websites.

 

Medium refers to systems, users, or groups that are valuable and support important business functions, and if compromised or unavailable would cause moderate disruption to business operations. These typically include: file servers, internal applications, non-critical databases, network infrastructure, executive users’ equipment.

 

High refers to systems, users, or groups that are critical to core business operations, if compromised or unavailable would cause significant disruption to business operations. These typically include: domain controllers, customer facing applications, compute resources processing or storing sensitive/regulated data, core financial systems, critical network infrastructure, privileged users and groups.

Time to Acknowledge refers to the process of identifying and classifying the level of risk or threat posed by an alert. The Initial Alert Notification SLO is measured from the time an alert is received by the TENEX.AI Platform until the alert transitions from “New” status to another status, such as “In Process,” “Under Review,” “Confirmed,” or “Dismissed.”

 

Time to Respond is defined as the time taken to execute the appropriate notification and/or escalation procedures for pre-determined event categories based on agreed-upon priority levels. The Time to Respond SLO is measured from the moment an alert is received and acknowledged by the TENEX.AI Platform until the Client is notified via predefined escalation channels, such as phone call, email, or text message.

 

Time to Resolve refers to the execution of pre-defined actions to mitigate a threat based on its priority level and the expected outcome. The Time to Resolve SLO is measured from the moment an alert is received, acknowledged, and responded by the TENEX.AI Platform until all agreed-upon mitigation activities are completed (e.g., implementing a temporary firewall block or submitting a request to Client’s IT team to re-image an infected machine).

 

Example Incident Flow and SLO Measurement Actions

To clarify the process, consider the following example incident scenario:

1. The Client’s security controls detect a malware infection that was not blocked by protective measures (e.g., an intrusion detection system identifies suspicious communication with a known malware command-and-control IP address).
2. The TENEX.AI Platform receives an alert from the Client’s intrusion detection system (IDS).
3. Within 15 minutes, TENEX.AI triages the alert and reclassifies its status from “New” to “In Progress,” meeting the Initial Alert Notification SLO.
4. TENEX.AI investigates the alert and, within two hours, notifies the Client of the suspected infection and ongoing analysis via the Client’s designated communication method (e.g., phone and email), thus meeting the Time to Respond SLO (two-hour response time).
5. After completing the initial investigation, TENEX.AI provides the Client with three recommended actions:
   • Blocking the malicious IP address on the Client’s firewall.
   • Deploying an endpoint signature to detect the malware threat.
   • Re-imaging the compromised machine.
6. The Client chooses to implement the firewall block and machine re-imaging but opts against adding a custom endpoint signature.
7. Within eight hours, TENEX.AI assists the Client in blocking the IP address and submitting an IT ticket for re-imaging the infected system. Since the agreed-upon mitigation steps were completed, this fulfills the Time to Resolve SLO.

Exclusions from SLOs

The following scenarios are excluded from the Service Level Objectives (SLOs):

 

• Incidents caused by Client actions (or lack thereof) that could impact log visibility or Google SecOps useability, including misconfigurations or unauthorized changes by Client personnel.
• Requests that are classified as non-standard after mutual agreement between TENEX.AI and the Client.
• Requests submitted by unauthorized personnel who are not designated Client points of contact.
• Delays in mitigation due to Client-side dependencies, such as change control processes, approvals, or procedural bottlenecks.