Threat Surveillance Product Terms.

Product Terms

The following Product Terms apply if the relevant Services are included within your Quotation. In the event of a conflict between the Product Terms and the applicable Terms and Conditions, these Product Terms shall prevail, but only to the extent of such conflict. Any capitalised terms used in this document shall have the meanings set out in the applicable Terms and Conditions (save where expressly provided otherwise below) and any additional definitions outlined below shall also apply.

In the Product Terms below, “Agent” shall mean each individual server on which the threat surveillance software agent is installed.

Service Definition

The Threat Surveillance service includes as standard:

* Host-based Intrusion Detection System (HIDS) log file collation;

* Vulnerability scans as specified on your Quotation on a schedule agreed and determined by the Customer and the Company in writing;

* File Integrity Monitoring; and

* Rootkit Detection (linux only),

in each case as more particularly set out below (“Standard Threat Surveillance”).

Customers may upgrade to a bespoke Threat Surveillance solution as set out in more detail below.

Charges

The pricing set out in the Quotation or on the Invoice is fixed during the Initial Term (as defined in the Agreement) on a per Agent basis and therefore the total amount payable will vary based upon the number of Agents required by Customer.

Any changes processed through an Quotation or within MyANS will be charged at the time of order and in advance of configuration.

Capabilities

Standard Threat Surveillance provides approximately 2,000 standard rules (in respect of which the Customer shall be provided with an overview description of the same).

Where Customer has purchased a bespoke Threat Surveillance set-up then additional Rulesets may be created as agreed by the Customer and the Company in writing.

SLA

1. Service Definition

In this Section the following words shall have the following meanings unless the context requires otherwise:-

Alert	This is an event that is triggered if a ruleset value is matched and exceeds a certain threshold. This is pre-defined on the Shared Platform. This will be unique for each Customer as this depends on the type of application and the type of server that is being monitored.
Bespoke Platform	The creation of custom rules and decoders, to specifically alert on log files generated by client custom applications.
Core System Files	The Company will work with the Customer during Discovery Days to determine which core system files the Customer wishes to be monitored. Should no core system files be specified by the Customer, or should the Customer choose the Standard Threat Surveillance option, we monitor the application defaults set out below. The defaults for Linux are: /etc,/usr/bin,/usr/sbin,/bin,/sbin The defaults for Windows are: win.ini system.ini autoexec.bat config.sys boot.ini CONFIG.NT AUTOEXEC.NT at.exe attrib.exe cacls.exe debug.exe drwatson.exe drwtsn32.exe edlin.exe eventcreate.exe eventtriggers.exe ftp.exe net.exe net1.exe netsh.exe rcp.exe reg.exe regedit.exe regedt32.exe regsvr32.exe rexec.exe rsh.exe runas.exe sc.exe subst.exe telnet.exe tftp.exe tlntsvr.exe drivers/etc Documents and Settings/All Users/Start Menu/Programs/Startup Users/Public/All Users/Microsoft/Windows/Start Menu/Startup
Discovery days	These are dedicated periods of time spent with a Customer to discover what technologies it uses and to understand how its solutions are set up so that the Company can modify its template rulesets and create bespoke set ups for Customers. Applicable only to a bespoke built environment.
Environment	The environment comprises of all Agents and threat surveillance servers as well as the infrastructure for aggregating data and generating alerts within the ANS Secure Zone.
Event	The parsed result of a single log entry.
File Integrity Monitoring	File integrity monitoring (FIM) is a control that performs the act of validates the integrity of files requested by the client or part of the default list included. This comparison method involves comparing a known checksum of the file monitored, with the checksum of the current state of the file. If this checksum is different, an alert will be generated and sent to the Customer.
Graphical Files	Reports which are generated at routine defined intervals, for example, weekly, monthly or quarterly. The Customer can change the frequency of such intervals.
Logs	A “log” represents the information taken from system events on monitored solutions. These are retained for one year from the set up time and date.
Patching	These are updates performed to system applications. These are applied to fix known security vulnerabilities. This will be recommended and performed after reviewing the Alerts for those customers who are also subscribed to Threat Response.
Raw Log Files	A log is an individual text record or multiple text records automatically created and saved by a server consisting of a list of activities it performed. The way these logs are parsed is defined by the global configuration policy for individual servers and formatting can differ depending on these global policies.
Reports	This is a report of the breakdown of all the vulnerabilities and policy-violating configurations detected. These are organised depending on whether they are critical, high, medium or low level vulnerabilities. The levels are defined through a combination of the use of the common vulnerability scoring system and the National Vulnerability Database. For more information visit https://nvd.nist.gov/ and https://www.first.org/cvss
Rootkit Detection	A rootkit is a computer program designed to provide privileged access to a computer while actively hiding its presence. Rootkits are generally associated with malware – such as Trojans, worms, viruses – that conceal their existence and actions from users and other system processes. Detection methods include behavioural-based methods (e.g., looking for strange behaviour on a computer system) and using signatures for well-known rootkits. Often, the only option to remove a rootkit is to completely rebuild the compromised system.
Rulesets	Policies which are used against the parsed log data to generate Alerts.
Shared Platform	Shared rulesets – no customisation
Threat Response	Threat mitigation services on Alerts identified through the Agent(s) on the Customer’s infrastructure.
ANS Secure Zone	Secure infrastructure that is used for alerting to clients and storing of log data for 12 month retention periods. Infrastructure is locked down and restricted to ANS security team only to minimise any risk of compromise occurring.

The following types of monitoring will take place in real time:

HIDS Log file collation

The Company provide a default list of Logs and Events collected, which can be customised for the Customer’s Environment during a Discovery Day with a Company security analyst, should the Customer wish to purchase a bespoke Threat Surveillance solution.

A central threat surveillance server may be located within the Customer’s management zone which all Agents will forward Logs to for ruleset analysis in real-time.

The Company has created Rulesets which analyse log files from all core technologies including but not limited to; syslog, mysql, sendmail, postfix, apache, sshd, sysmon, all windows event logs, squid, php, apache, nginx, cisco ios, telnet, postgres, openbsd, clamav,pam, puppet, opensmtp.

If any rules are triggered an Alert will be sent to the Customer directly and be visible in the client interface.

Reporting of threat surveillance activity will be displayed within MyANS in both a graphical format as well as Raw Log Files, this is monthly by default but can be scheduled as the Customer requires and agreed in writing by the Company.

File Integrity Monitoring

During initial discussions with a view to scoping out the Threat Surveillance Service the Customer will provide the Company with certain core system files or directories they would like to be monitored and any changes tracked. The biggest application seen for this is ensuring payment gateway or redirect pages are not manipulated to send customer payments elsewhere. A hash of the file is taken, any changes to the hash generates alerts which are sent directly to the Customer, with the time, date and user who made the changes.

Internal Vulnerability Scanning

A scheduled Vulnerability Scan will be run which detects any components that require Patching and updating along with a severity rating. These reports are sent to the Customer as requested or on a schedule. These reports will be available as soon as the scan has completed.

2. Support hours

Threat Surveillance is a monitoring and alerting product and does not include any threat mitigation or remediation. Threat mitigation (Threat SOC) is an additional service which may be requested by the Customer.

3. Self-help website

The Company will use reasonable endeavours to maintain and make accessible to the Customer, a website containing guidance intended to enable the Customer to resolve problems in use and operation of the Platform and statistics for support tickets.

Notifications

Customers will be sent reports on a monthly basis and will be sent real time alerts via email.

Alerts have been categorised as the following:

Levels 1-5: Low level events.

Expected on systems as day to day use.

Levels 6-10: Normal Events.

Categorised as user activity that is expected but should be monitored.

These are events such as successful logins from IPs that are expected and during normal hours; as are determined by normal custom and practice. Normal practiceis determined by reference to a usual working day of 8-6pm.

11 – 13: High Severity Alerts.

Will need immediate investigation, such as successful logins from unknown IP addresses, change of user account permissions.

14- 16: Critical alerts.

Investigate immediately, indicators of a system compromise, such events as successful logins after failed attempts, modifications to core system files, modifications to payment gateway files.