🌙
 

Subscribe to the Taegis™ XDR Documentation RSS Feed at .

Learn more about RSS readers or RSS browser extensions.

Secureworks Managed iSensor on Taegis XDR

service descriptions isensor


This Service Description (“SD”) describes the Secureworks® Managed iSensor® Service (“Service”). All capitalized words and phrases shall have the meanings set forth herein, as defined in the Glossary, or within the Secureworks-applicable agreement, such as the Customer Relationship Agreement.

This is a managed Service. As such, Secureworks® performs Device management functions, which can include changes, rule/policy modifications, upgrades, and similar functions, upon Customer request. Secureworks also performs monitoring and alerting of Device health and Security Events (for events generated from one or more Devices).

Overview

The Service enables detection and prevention of network-based threats using the iSensor appliance (“iSensor”) that can be deployed as a virtual or physical appliance within Customer’s network. iSensor uses Secureworks Threat Intelligence to detect and prevent network-based threats. As network traffic is inspected, iSensor compares it to the integrated signatures to identify and block malicious traffic in real time.

Secureworks will manage Customer’s iSensor appliances (referred to as “Devices” in this SD) on an ongoing basis. Customer will lease or purchase Devices from Secureworks and install them in Customer’s environment to enable delivery of the Service.

Secureworks will work with Customer to ensure proper connectivity of the Devices and will monitor the Devices on an ongoing basis to detect signs of advanced threats and threat actors, search for specific indicators of compromise, maintain updated threat intelligence, analyze event data, and send alerts to Customer with recommendations on how to proceed should threat activity be detected. To perform these activities, the Devices will send event data to the Secureworks Security Operations Platform (“Platform”) for processing and analysis. This Service enables detection of threats and threat actor activity that some technologies (e.g., common anti-virus software) are unable to detect.

The Service allows for maintaining/storing key forensic data necessary to make threat detection and response faster and more efficient, and reducing effort required to investigate and respond to threats.

The Service includes the following components:

See the Service Details section for more information about the Service, including further explanation of the components listed above. Also, see the Secureworks MSS Services – Service Description Addendum for information about the following, as applicable to the Service: Device responsibilities, Maintenance Program, and Subscription Program.

Note

Secureworks will not install third-party software on any appliance or system, unless explicitly indicated in the Service Details section as being part of the Service.

Customer Obligations

Customer will perform the obligations listed below and acknowledges and agrees that the ability of Secureworks to perform its obligations hereunder, including meeting the Service Level Agreements (“SLAs”) listed further below, are dependent on Customer’s compliance with these obligations. Noncompliance with Customer obligations relative to this Service may result in suspension of the Service.

Connectivity

Customer will provide and maintain remote network connectivity to Customer’s environment, including ensuring sufficient network Bandwidth, and the in-scope Device(s) that are necessary for Secureworks to perform the Service. Customer will also allow connectivity from Secureworks IP range to Customer location(s) as applicable to the Service. SLAs will not apply to the Device(s) that is experiencing connectivity issues that are beyond the control of Secureworks.

Application Program Interface (“API”) Integration

Some vendors provide APIs to interact with their systems. Any script or code creation for, usage of, maintenance of, or integration with other third-party tools are not included in this Service; Customer will be responsible for all API integration, and related activities and licenses. Secureworks will not install any third-party software applications that use the API directly on the appliance.

Communications

Customer will communicate with the Secureworks Security Operations Center (“SOC”) through telephone (Customer-authorized representative will be authenticated) or through the Platform using Chat. Customer should submit all Service-related issues or requests via the Chat interface in the Platform. It is Customer’s responsibility to ensure that its list of authorized representatives is up to date with the Secureworks SOC. Customer is responsible for timely responses to communications that Secureworks escalates to Customer through the Platform.

Maintenance

Customer will notify the Secureworks SOC through the Chat interface in the Platform at least 24 hours in advance of planned Customer-side network maintenance to enable Secureworks to avoid unnecessary escalations to Customer.

Usage Overage and Use Restrictions

If, for any services identified in Customer’s Service Order(s), Customer’s actual usage exceeds the subscription limit of such services (“Overage”), then Secureworks may invoice Customer for Overage, and Customer will pay for the Overage as applicable to Customer’s actual usage, from the date Secureworks identified the Overage until the end of the Services Term.

Customers receiving this Service shall be provided access to the Secureworks Security Operations Platform for the purpose of receiving the Services described herein and reviewing Managed iSensor data. Customer shall not add additional data sources to the Secureworks Security Operations Platform or deploy endpoint agents unless Customer has entered into a XDR trial agreement or has ordered additional XDR products or services pursuant to a new Transaction Document. The addition of new data sources or the deployment of endpoint agents shall be considered an Overage as defined above.

Virtual Environment

Customer is responsible for Customer’s virtual environment. Customer will provide the Guest Virtual Machine (“Guest VM”)—which resides on a Hypervisor—on which the Secureworks-provided image (the Virtual iSensor) will be installed. Customer must provision the Guest VM with the following required resources for proper functionality and delivery of the iSensor: CPU, memory, storage capacity, and network resources.

Secureworks provides two images for the Virtual iSensor. Provided below are the Secureworks default specifications for each image. These specifications may need to be adjusted depending on iSensor performance and the amount of inspected network traffic. Customer must install one of the images on the Guest VM, and Customer will need to adjust the settings for the iSensor as needed to meet the demands of Customer’s environment.

Item Small Image Large Image
CPU 4 cores 8 cores
Memory 4 GB 8 GB
Storage 60 GB 60 GB
Inspection Throughput 500 Mbps 1,000 Mbps

Hardware and Software Procurement

Unless Customer chooses to use a virtual iSensor, Customer will purchase or lease the hardware necessary for Secureworks to deliver the Service. If a virtual iSensor will be used, then Customer will download the applicable software from the Secureworks-provided download location.

General

Initial Implementation Scheduling and Points of Contact

Secureworks will contact Customer within seven (7) Business Days after execution of the Service Order (“SO”) to schedule the first meeting during which Service Implementation will be discussed.

Customer and Secureworks will designate respective points of contact (“POC”) to facilitate communication and support ongoing activities related to implementation of the Service.

Service Details

The subsections below contain details about the Service and how it will be implemented.

Service Components

The subsections below contain information about the components of the Service.

Security Event Monitoring and Alerting

To provide Customer with Security Event monitoring and alerting of potential threat actors and threat activity, Secureworks will use a combination of the following:

Secureworks aggregates and analyzes data from the above-listed sources and uses the data to conduct security activities that help Customer prevent and defend against attacks. The data from these sources enables faster detection of malicious activity, and action against the activity. As new threat activity is identified, new detectors are developed and deployed to the Platform, providing customers with protection from threat actors and threat activity.

Secureworks only monitors and alerts Customer of threat actors and threat activity using the above-listed sources (includes data from Devices or Security Events that are provisioned and maintained as part of the Service); no other sources such as Customer-created alerts and custom watch lists, or TI from other sources will be used. Secureworks reserves the right to change how monitoring and alerting is conducted and conduct maintenance at any time to ensure the best quality of TI is applied promptly. Customer-created custom alerts can be configured for monitoring and alerting. Customer can submit a Service Request to Secureworks, and Secureworks will work with Customer to evaluate the request and determine how to proceed. Secureworks does not monitor the availability of the threat intelligence sources that are used for these customer-created custom alerts and will not be subject to penalties associated with the Security Monitoring SLA if the sources become unavailable.

Security Events from the iSensor are sent to the CTA(s), and from the CTA(s) to the Platform where they are parsed, normalized, correlated, and prioritized. Secureworks prioritizes Security Events based on severity as indicated in the Security Event Prioritization and Security Incidents section.

Security Incident Identification Methods

Secureworks will use two methods to identify and act upon Security Incidents, as explained in the table below.

Identification Description
Real-Time Security Incidents Upon receiving alerts that are triggered by Devices, Secureworks will process all Security Events to identify patterns that may indicate malicious activity. This process includes analyzing Security Events to add additional context to activity and help reduce the number of false-positive Incidents. Security Events that are malicious will be logged as Security Incidents, and further action will be taken, as applicable to the Security Incident.
Retroactive Security Incidents Secureworks will use a combination of machine learning and look-back alerting for newly discovered threat indicators to identify patterns of malicious activity over extended periods of time to generate and analyze Security Incidents. Security Incidents generated from this retroactive analysis are not subject to the Security Monitoring SLA.
Security Event Prioritization and Security Incidents

Secureworks analysts will monitor all high and critical alerts generated by the Device. When a high or critical alert triggers a true positive, a Security Investigation (based on Security Events) will be created within the Platform, and Customer will be notified using a combination of notifications through email, telephone, and within the Platform. The Security Investigation contains details about the alert (e.g., time, hostname, IP addresses, user information), related alerts that provide additional context, and remediation steps.

Investigation Severity Description
Critical / High Security Events that require immediate attention and/or represent potential business impact to Customer environment (e.g., targeted threats, opportunistic malware infection)
Medium Security Events that do not require immediate attention and typically represent pre-compromise, compliance, audit, reconnaissance, or other types of activity that is unlikely to indicate a significant threat to Customer environment
Low Security Events that may represent a misconfigured security control, false positive-prone countermeasures, and other activity that has little to no impact to Customer environment
Security Incident Analysis and Information

Upon determination of a Security Incident, Secureworks will conduct analysis to provide Customer with as much information as possible through the Security Incident investigation in the Platform. Not all Security Incidents will have the same information available (depends on one or more detection methods) and as such, the information provided can vary between Security Incidents. The following are examples of information that will be provided:

In-depth analysis, incident response, forensics, and countermeasure implementation beyond policy changes to Devices are not included in this Service. Customer can purchase these services through a separate, signed SO or SOW.

Retroactive Security Incident Investigations

Security Incidents that are considered retroactive (i.e., “Retroactive Security Incidents” in the above table) are escalations developed from applying newly identified indicators to historical logs, researchers manually reviewing alerts from countermeasures still under active development (i.e., research for developing new countermeasures), and other similar processes. Researchers investigate threats and relevant details to determine Customer impact, and to develop new countermeasures.

Retroactive escalations may be related to threats still being actively researched and/or ongoing Security Incidents. As such, details related to Retroactive Security Incidents may be limited or privileged.

There is no limit on the number of Secureworks-initiated Retroactive Security Incident investigations that will be conducted for Security Incidents that are created based on Secureworks TI and external resources such as Secureworks trusted partners and OSINT.

Details that can be provided to Customer are added to the Security Incident investigation in the Platform.

Security Event Reporting

Customer can use the Platform to create, customize, and access executive and technical level reports, and view and report on detailed, historical Security Event data. Customer will be able to create both standard and customized reports.

Device Availability and Event Flow Monitoring and Alerting

Secureworks must be able to connect to the Device(s) using Internet Control Message Protocol (“ICMP”) or Secure Shell (“SSH”) depending on the platform type. Secureworks conducts availability validations on the Device(s) to confirm availability.

Upon detection of loss of device availability, Secureworks will notify the Customer through electronic notification within the time specified in the SLA. Secureworks will then perform additional troubleshooting to resolve any availability issue. If such troubleshooting is unsuccessful, then Secureworks will notify the Customer through telephone, ticket, or electronic notification. After such Customer notification, Secureworks will work with Customer to perform further troubleshooting steps until the issue is resolved and worked to identify root cause.

Secureworks will attempt to restore event flow if the root cause is determined to be related to the Device(s). Secureworks will work with Customer’s designated POC(s) to address any Device-related issues.

If the root cause of the issue is not related to the Device (e.g., a Customer-side network change, outage, or misconfiguration), then Secureworks will provide Customer with troubleshooting information, but Secureworks is not responsible for troubleshooting issues that do not directly relate to the managed Device(s), Equipment, or Secureworks networks and environments.

Software Maintenance for Devices

Components of the iSensor Device, which may include Secureworks or third-party software, may occasionally require updating. Secureworks will install software patches and updates as part of the Service when the following conditions apply:

When vulnerabilities are disclosed, Secureworks assesses the applicability of each disclosure (and related patch or patches, if available) to Customer’s managed Devices. Secureworks will notify Customer about critical vulnerabilities that apply to managed Devices.

Return Materials Authorization (“RMA”) Assistance

If a Device that Secureworks is managing for Customer is determined to be in a failed or faulty state and requires replacement, then Secureworks can initiate and fulfill the RMA process with the managed Device’s vendor on Customer’s behalf. Customer is responsible for maintaining a valid support contract and licensing for the Device. Customer is also responsible for associating Secureworks with the vendor support contract.

Service Delivery

The subsections below contain information about how Service and support are delivered to Customer.

Security Operations Centers (“SOCs”)

Secureworks maintains SOCs in the United States and internationally. To provide Service to Customers around the world, Secureworks administers security services and support from these SOCs, such as monitoring Security Events, aggregating and correlating data, conducting analysis, escalating Security Events, and performing other security-related activities. Contact information for the SOCs will be provided to Customer.

Business Days and Business Hours

Business Days for Secureworks global headquarters are Monday – Friday and Business Hours are 8 a.m. – 5 p.m. US Eastern Time, excluding US holidays. Business Days and Business Hours for all other Secureworks locations vary according to local time zone and country. The Secureworks SOC is available 24 hours a day, 7 days a week, for questions and support. During non-Business Days and Hours, some SOC inquires may be sent to other support groups to address during Business Days and Hours.

Service Location(s) and Languages

The Service will be delivered remotely from a Secureworks location(s). Voice and email support are provided in English only. Other components of the Service that are visible to Customer (such as reports, documentation, and the Platform) are provided in English only. Additionally, Secureworks requires that inputs and interfaces to the Service, including but not limited to logs, Application Programming Interfaces (“APIs”), and Command Line Interfaces (“CLIs”), be provided in English. Service options and availability may vary by country; contact Secureworks sales representative for details.

Service-Enabling Technology

Customer will be provided with access to the Platform. In addition, one or more CTAs will be provisioned. Below are explanations of these items.

Secureworks Operations Platform

The Secureworks Security Operations Platform provides the following:

Access to the Platform is enabled for Customer-specified authorized users during the Organize phase of service implementation (see the Initial Implementation section for more information), and training regarding Platform use is conducted during the Execute phase of service implementation. It is Customer’s responsibility to ensure that access for authorized users of the Platform remains current.

All information received by Customer through the Platform is solely for Customer’s internal use and may not be re-distributed, resold, or otherwise transmitted outside of Customer’s organization.

Counter Threat Appliance

The Service requires a physical and/or virtual CTA(s) to communicate with Client-Side Technology (e.g., for data collection and transfer for monitored Devices). CTAs should be provisioned in advance of Service Commencement Date and meet minimum hardware and version requirements.

Customer and Secureworks Responsibilities

The responsibility assignment matrix below describes the participation required by both Customer and Secureworks in completing tasks or deliverables for a project or business process to facilitate successful service delivery. Secureworks uses standard RACI role criteria for managing Customer projects and deliverables. These roles are defined as follows:

Note

The SOC provides Quick Start guides to Customer, which contains more detail about SOC-specific roles and responsibilities.

Activity Task Customer Secureworks
Service Preparation Provide contact information for authorized contacts regarding Customer’s account R, A I
Provide information for authorized users who need access to the Platform (Customer will modify as needed at any time through the Platform, and add / remove users as needed) R, A I
Provide shipping information for Secureworks to send physical Devices required to implement Service R, A I
Create and provide to Secureworks the escalation procedures to follow for investigations (Customer will modify as needed at any time through the Platform) R, A I
Enter Customer’s initial escalation procedures into Platform A, C, I R
Provide information on support requirements, sizing recommendations and sample deployment scripts (applicable to Public Cloud Environments only) I R, A
Provide to Customer the implementation guidelines for service implementation I R, A
Ensure managed Device(s) meets Secureworks-provided hardware and software specifications prior to the start of implementation R, A C, I
Ensure managed Device(s) meets minimum third-party vendor hardware and software specifications prior to the start of implementation (if applicable) R, A C, I
Prepare the environment as required to implement Service, which may include rack space, power, cooling, network connectivity, public cloud access, or other modifications R, A I
Send CTA(s) to Customer-provided location(s) (if using physical CTAs) I R, A
Service Implementation Provide information (e.g., host name, IP address) that Secureworks will use for Devices R, A I
Provide Secureworks with access (e.g., login credentials, access to Customer network) to Devices R, A I
Implement all requirements per guidelines provided to Customer by Secureworks R, A I
Install the CTA(s), and use cables to appropriately connect the CTA(s) to the network R, A I
Finish configuration of CTA(s) (remotely) I R, A
Configure implementation rules on Customer side based on guidelines provided by Secureworks, vendor, or both, as applicable R, A I
Configure implementation rules in the Secureworks environment I R, A
Configure Devices for Security Event logging I R, A
Configure initial Platform access for Customer’s authorized users
Provide training (remotely) to Customer for Platform I R, A
Provide Customer-side post-install validation steps to Customer I R, A
Complete Customer-side post-install validation steps R, A I
Complete Secureworks-side post-install validation steps I R, A
Security Monitoring Conduct daily monitoring activities to include review, triage, and forwarding of Customer-related validated alerts/Security Events/Security Incidents for next steps I R, A
Conduct incident response activities for alerts, Security Events or Security Incidents identified by Secureworks R, A I
Monitor Service-specific logs and create Security Events or Security Incidents for security concerns C, I R, A
Conduct real-time analysis of Security Events that are created (manually create Security Incident investigations if needed); escalate Security Incidents as applicable, using Customer’s escalation procedures C, I R, A
Conduct log correlation to identify internal sources/destinations of traffic related to escalated Security Incidents (if applicable) I R, A
Submit through Platform (or otherwise contact SOC to submit) request to create custom IP watch lists and related alerting procedures (submit changes to watch lists and alerting procedures through Platform as needed) R, A C, I
Implement Customer-provided custom IP watch lists and related alerting procedures (update as needed, upon request from Customer) C, I R, A
Remediate all malware and threat actor activity R, A I
Investigate and confirm validity and potential business impacts of changes (i.e., conduct due diligence) prior to submitting a change request in Platform for implementation R, A I
Submit through Platform (or otherwise contact SOC to submit) all change requests for Devices; ensure requests are internally vetted and approved within Customer’s organization, and include all information necessary to implement each request R, A I
Change Management Advise Secureworks of appropriate timing for maintenance window to perform changes (e.g., Customer-submitted change requests) and maintenance (e.g., in-scope software upgrades) for Devices R, A C, I
Perform maintenance that is specific to Customer’s environment and implement Customer-submitted change requests during the Customer-designated maintenance window C, I R, A
Perform validation on completed changes to Devices in Customer’s environment R, A C
Notify Customer (through Platform or email) that requested change was completed I R, A
Provide explicit approval for Secureworks to implement emergency IP blocks without first obtaining Customer approval (optional) R, A C, I
Implement emergency blocking-rule changes as necessary (e.g., to address real-time malicious traffic) C, I R, A
Advise Customer of emergency blocking-rule changes after implementation C, I R, A
Notify Secureworks through Platform or telephone of issues that occur after changes have been implemented R, A I
Investigate Customer-reported issue(s) with changes made, and revert to previous state if Secureworks-implemented changes caused issue(s) A, C R
Conduct ad-hoc changes and troubleshooting that is out of scope for the Service R, A I
Investigate Secureworks-identified health-related issues (e.g., a system event such as a memory threshold being exceeded) on Devices R, A C, I
Conduct troubleshooting related to the Service to determine root cause of an issue C, I R, A
Support Support validation (including validation for health-related issue) for upgrades and updates implemented on Devices I R, A
Work directly with Device vendor on Customer’s behalf to execute RMA activities C, I R, A
Initiate RMA process to send replacement Device(s) to Customer as needed and according to Customer eligibility C, I R, A
Return failed Device(s) to Secureworks R, A I
Install Secureworks-provided RMA replacement Device(s) for Secureworks remote access (includes minor network configuration and account creation) R, A C, I
Notify Secureworks after RMA Device is installed and connected to Customer’s network R, A I
Conduct software upgrades and configuration changes that are in scope for the Service (software must be Secureworks supported) C, I R, A
Provide on-site personnel to assist to Secureworks while conducting Device software upgrades, hardware changes, Device power cycling, and any activity that must be physically performed on-site R, A C, I
Send electronic notification to Customer about critical Device vulnerabilities and requests for authorization to apply a patch or patches (if applicable to one or more Devices) C, I R, A
Provide support to Customer for issues relating to the Platform C, I R, A
Create and maintain scripts for health-specific events to monitor status of Devices I R, A
Send electronic notification to Customer about Secureworks-identified health event issues or concerns I R, A
Notify Customer through electronic notification of connectivity loss for managed Devices within the time specified in the Health Monitoring SLA I R, A
Ensure Secureworks has current contact information for authorized contacts regarding Customer’s account R, A I
Provide Secureworks with advance notice of Customer-authorized scans or Customer network maintenance periods (to avoid unnecessary Secureworks escalations resulting from these activities) R, A I
Provide Customer network design and specification for integration with Secureworks services (includes auditing and providing updated designs and specifications when changes are made) R, A I
General Maintain network ranges (e.g., public, DMZ, and private) and network translation devices (e.g., NAT pools, proxies, and load balancers) R, A C, I
Notify Secureworks of any changes to network ranges (e.g., public, DMZ, and private) and changes to network translation devices (e.g., NAT pools, proxies, and load balancers) R, A C, I
Maintain valid vendor support contracts for all managed Devices R, A I

Secureworks Platform Maintenance

To ensure Customer receives the highest level of Service possible, Secureworks will conduct platform maintenance (updates, upgrades, patching, and other platform-specific work) on a periodic basis, as maintenance changes are validated and approved for release into the Secureworks platform. Secureworks follows internal change control processes to ensure platform stability. Generally, maintenance does not require a network outage. Secureworks will conduct platform maintenance without Customer approval or a maintenance window when a network outage is not required. Customer acknowledges and agrees that approval or a maintenance window is only mandatory when a network outage is required.

Support for Private Virtual Environments

Depending on Device types, Customer’s environment, Customer’s requirements, and other criteria, Secureworks provides support as described herein, for a single-tenant Private Virtual Environment that is located on Customer’s premises as part of a service that Customer purchases from Secureworks. The information in this section is part of Customer agreement with Secureworks, and takes precedence over any conflicting information elsewhere in this SD. The subsections below contain information about Customer responsibilities, Secureworks responsibilities, and out-of-scope services regarding a Customer’s Private Virtual Environment. See the Glossary for definitions of terms related to virtualization that are used in this SD.

Customer Responsibilities

Customer agrees to the responsibilities explained in the subsections below and acknowledges and agrees that Secureworks’ ability to perform its obligations and responsibilities, and its liability under the SLAs, are dependent upon Customer’s compliance with these responsibilities.

Provisioning and Maintenance

Customer is responsible for all aspects of provisioning (installation, configuration, and setup) of supported Hypervisor technology, such as VMware, including but not limited to the following:

Customer must perform all maintenance for the Guest VM, which includes the items listed below:

VMs

Customer is responsible for providing the Guest VM(s) on which the Secureworks-provided image (the vCTA) and, if applicable, Virtual Security Appliance (“VSA”) will be installed. Customer must provision the VM with the required central processing unit (“CPU”), memory, storage capacity, and network resources needed for proper functionality and delivery of the Service. Customer shall provide Secureworks with a privileged account with access to the Guest VM(s). This account may also be used for automation purposes. The OS on the Guest VM must have a valid license for support. Secureworks will not provide any assistance without in-band access to the Guest VM and without a valid license.

Secureworks Responsibilities

Secureworks is responsible for providing the vCTA and, if applicable, VSA, providing support to Customer during provisioning of the vCTA and VSA, and managing and monitoring the vCTA and VSA that are operating on the Guest VM(s). Customer must maintain a suitable environment in which to operate the Guest VM(s) that is being used for the vCTA and VSA. This includes using a Secureworks-supported Hypervisor version.

Shared Responsibilities

VSA and vCTA Upgrades

Secureworks will implement upgrades only for the VSA and vCTA on the Guest VM, as applicable to the Service; Customer is responsible for any other upgrades (e.g., Host/Guest VM, Hypervisor).

VSA and vCTA Backups

Secureworks will back up the configuration for the VSA and vCTA only. It is Customer’s responsibility to back up (and otherwise maintain) the image or virtual hard disk for the Guest VM. If a Guest VM requires a rebuild, then Secureworks will restore the prior vCTA configuration after Customer restores the Guest VM and its connectivity. Secureworks recommends that any virtual infrastructure be deployed on redundant systems.

VSA and vCTA Health, and Adding Capacity

Secureworks will perform health-related validations on the VSA. Secureworks must be able to connect to the VSA through the Internet using ICMP and SSH. Each VSA is always assumed to be powered on, and any disappearance of a VSA from the network is considered a failure.

Secureworks will monitor the vCTA. If it is determined that a health-related issue caused by performance of the Host/Guest VM hardware, or insufficient capacity for the Guest VM, is negatively affecting the vCTA, then it is Customer’s responsibility to resolve the performance issue or add sufficient capacity to the Guest VM.

Secureworks conducts availability validations on the VSA and vCTA to confirm availability. Upon detection of loss of Device(s) connectivity, Secureworks will notify Customer through electronic notification, and Customer will troubleshoot networking issues. If such troubleshooting is unsuccessful, then Customer can contact Secureworks to jointly find the root cause and remediate the issue.

Health monitoring is limited to VSAs, CTAs, and other Devices. Secureworks does not perform health monitoring for Hypervisors or underlying hardware.

Out-of-Scope Services in a Virtual Environment

The following are considered out-of-scope for this Service:

Out of Scope

The information in the Service Details section comprises the Secureworks standard in-scope offering for the Service. Any other services or activities not specifically listed as in scope are out of scope. Items listed below are examples of services and activities that are out of scope. Upon request, Secureworks can provide out-of-scope technical support on a time and materials basis pursuant to a separate SO or Statement of Work (“SOW”).

Service Fees are based on the amount of network Bandwidth Customer will be using. For Customers using 100MB or less, the number of users is also considered. See Customer’s MSA or CRA (as applicable), and SO or SOW (as applicable) for details, including the following:

If during the course of activation, the monitoring component of this Service is activated prior to the management component, Customer acknowledges that Secureworks reserves the right to commence invoicing Customer, and Customer agrees to pay for the monitored component provided by Secureworks, in accordance with billing terms in the MSA or CRA and based on the then-current Secureworks list price for the monitoring component(s) activated, until such time as the management component is activated, at which time invoicing for the full service fee will commence.

Invoice Commencement

See the Service-specific Addendum or SO for information about invoice commencement.

Service Level Agreements (“SLAs”)

The table below contains the SLAs that are applicable to the Service.

SLA Description Credit
Security Monitoring (Security Incident analysis) Secureworks will monitor iSensor for Threats. When malicious activity is detected, Secureworks will triage, perform an Investigation, provide an analysis, and notify Customer.

Subsequent related activity identified as part of the ongoing Investigation or monitoring will be appended to an existing Investigation.

Customer shall receive electronic notification of a security incident within fifteen (15) minutes of the determination by Secureworks that the given activity constitutes a security incident.

This is measured by the difference between the investigation “Assigned to Customer” time stamp and the time stamp of the correspondence to the Customer documenting the initial escalation.

Security incidents generated from long-term correlation logic and retroactive analyses based on newly identified threat indicators are not subject to this SLA.

Event(s) deemed low and medium severity may be sent to Customer for review and will be available through the Platform for reporting.
1/30th of monthly fee for Service for the affected Device
Health Monitoring Health incident validation identifying unreachable Devices: 30-minute response time through alert in Platform, or other electronic notification; measured as the difference between the status change in the Platform to the time stamp of the first correspondence documenting the initial escalation to Customer. 1/30th of monthly fee for Service for each calendar day on which Device unreachable event(s) were not communicated to Customer in the specified timeframe, up to, but not exceeding, 100% of the monthly fee for Service
Service Request A service request (applies to all non-change and non-incident tickets) submitted through telephone or the Platform will be acknowledged through human or electronic notification (e.g., Platform) within one (1) hour from the creation time stamp on the ticket.

Customer must contact SOC through telephone or the Chat in the Platform for immediate engagement with urgent service request tickets.
1/30th of monthly fee for Service for each calendar day the service request was not acknowledged within the specified timeframe
Availability Customer access to the Platform shall equal no less than 99.9% of the time during any calendar month.

“Customer access to the Platform” is defined as the ability of the customer to log in to the Platform.
1/30th of monthly fee for Service each day in which the Service fails to meet this SLA

Warranty Exclusion: While the Service is intended to reduce risk, it is impossible to completely eliminate risk, and therefore Secureworks makes no guarantee that intrusion, compromises, or any other unauthorized activity will not occur on Customer’s network.

The SLAs set forth above are subject to the following limitations:

For Customer to receive an SLA credit, subject to the limitations above, the notification of the SLA failure must be submitted to Secureworks within thirty (30) days of the date of such SLA failure. Secureworks will research the notification and respond to Customer within thirty (30) days from the date such notification is received. The total amount credited to Customer in connection with any of the above SLAs in any calendar month will not exceed the monthly Service fees paid by Customer for such Service. The foregoing SLA credit(s) shall be Customer’s sole and exclusive remedy for failure to meet or exceed the foregoing SLAs.

Additional Considerations and Information

Secureworks provides its Lifecycle Policy in PDF format through this link: Secureworks Lifecycle Policy. This policy includes information for customers purchasing service bundles and products. Customer can also access the Secureworks Hardware and Software Support Status matrix, End-of-Sale (“EOS”) and End-of-Life (“EOL”) notifications, and other information through the aforementioned link. Secureworks reserves the right to alter the General Availability (“GA”), EOS, and EOL dates at any time for any reason. Secureworks is not responsible for errors within the Hardware and Software Support Status matrix.

Glossary

Term Definition
Bandwidth The amount of network traffic, measured in bits per second, that is being inspected by the associated iSensor.
Counter Threat Appliance ("CTA") Equipment that specifically allows Secureworks to collect data while performing a Secureworks-defined service for Customer, such as monitoring Customer’s network and environment for security threats.
Counter Threat Unit (“CTU”) Internal team of security experts that research and analyze threat data across Secureworks global Customer base and actively monitors the threat landscape. Provides threat intelligence that extends visibility into cyber threats beyond the edges of the networks of Secureworks Customers. The threat intelligence, applied to technology and the Secureworks suite of services, enables Customers to expand visibility and reduce the time it takes to see and respond to them, thereby resisting and avoiding cyberattacks.
Customer Device(s) One or more Devices that are owned by Customer and were not purchased from Secureworks.
Device(s) Equipment that is in scope for the Service.
Due Diligence Validating the accuracy of information used to create Customer’s original Service Order against the actual environment in which services will be performed.
End of Life ("EOL") The date on which all support for a product ends, which includes any software upgrades, hardware upgrades, maintenance, warranties, or technical support.
End of Sale ("EOS") The date on which a product is no longer available for purchase.
Endpoint An Internet-capable computing machine or end unit such as a desktop computer, laptop, server, or another similar device that could host a compatible endpoint agent whether that agent be deployed on premises, hosted, or in the cloud. See What is an Endpoint? for details.
Identified Changes Differences (e.g., Device quantity, make, model, software package, or software version) that are discovered while conducting due diligence for the Service.
In-Band Activity within a defined telecommunications frequency band.
Private Virtual Environment Customer’s on-premises virtual infrastructure.
Public Cloud Environment Third-party virtual infrastructure that hosts the Customer’s network and security devices.
Secureworks Security Operations Platform ("Platform") The platform that helps protect customers by ingesting security-relevant data, applying analytics to detect known and unknown threats, and supporting a streamlined response process.
Security Event Identified occurrence of a system or network state that may be malicious, anomalous, or informational, which is ingested into the Secureworks technology infrastructure.
Security Incident One or more related and identified Security Events that can potentially impact the confidentiality, integrity, or availability of a Customer’s information or systems, and requires further analysis and disposition.
Service Level Agreement ("SLA") A legally-binding arrangement to meet defined standards for the Service.
Definitions for Virtual Environments
Guest Separate and independent instance of operating system and application software that operates on a Host.
Host Virtual Machine host server that provides the physical computing resources, such as processing power, memory, disk, and network I/O.
Hypervisor Virtual Machine monitor that isolates each Guest, enabling multiple Guests to reside and operate on the Host simultaneously.
Virtual Contexts A form of virtualization where one physical firewall is divided into two (2) or more virtual firewalls..
Virtual Machine (“VM”) A logical instance of the physical Host that houses the operating system of the Guest.
Virtual Security Appliance (“VSA”) Software implementation of a security device–e.g., a log retention appliance, scanner appliance (VMS), intrusion detection system–that executes programs in the same manner as a physical machine.

 

On this page: