Appendix B1 - Statement of Work Compliance Assessment
| Ref | Requirement | Compliance | Notes |
|---|---|---|---|
| 1 | CONTEXT | ||
| 2 | 1.1 “System” or “Solution” refers to Endpoint Protection Platform (EPP), Endpoint Detection and Response (EDR) with Extended Detection and Response (XDR) and Managed Extended Detection and Response (MXDR) services, as further detailed below. | ||
| 3 | 1.2 The Supplier will provide and implement the System for the Company, as well as provide all licences, hardware, software, developments and/or deliverables operating in conjunction with each other in particular those described in this Appendix B1, and any computer programmes, databases, the tangible media on which they are recorded and their supporting documentation, including input and output format, programme listings, narrative descriptions, source code, object code, operating instructions and user manuals. | ||
| 4 | 2. ADDITIONAL Definitions | ||
| 5 | 2.1 "Services" means the Services which the Supplier is required to perform under the LOA, such Services to comply with the Company’s requirements, which includes but is not limited to installation, design, planning, upgrading Services, warranty, maintenance and/or the provision of materials required thereof. | ||
| 6 | 2.2 “Goods” means all items including the hardware and software that the Supplier is required to supply under this LOA as listed in Appendix B2 including any optional items or accessories. | ||
| 7 | 2.3 The Goods / Services shall conform in all respect to the Description of Goods/ Services as set out in Appendix B1. | ||
| 8 | 2.4 The Supplier shall ensure that the Goods / Services and every part or unit thereof are new and manufactured in a good workmanlike manner with proper design and materials and that the Goods / Services shall be free from defects including defects arising out of faulty design, inferior materials, faulty and inferior workmanship. | ||
| 9 | 2.5 The Supplier warrants the Goods to be fit for the purpose intended and in accordance with the provisions as set out in Appendix B1. | ||
| 10 | 2.6 The Supplier shall provide the Goods/ Services with professional skill, care and diligence to a standard consistent with good practice as then current in the relevant area of the information technology industry. | ||
| 11 | 2.7 In the event of any difference in the specifications, the more stringent requirements in favour of Company shall prevail. | ||
| 12 | 2.8 The Supplier shall, at no additional charge, supply and deliver all documentation (including | ||
| 13 | 2.9 documentation), in relation to the Goods/Services, in both hardcopy and softcopy form. All data, documentation, description, diagrams, books, catalogues, advisory services, instructions and correspondence shall be written in readily comprehensible English language. | ||
| 14 | 2.10 The Supplier shall submit to Company such information and assistance as may be necessary to enable Company, whether by itself or to direct any third party, adequate time to prepare the Site for the installation of the Goods and to provide the necessary environmental and operational conditions for the efficient working and maintenance of the Goods. | ||
| 15 | 3. UNAUTHORISED CODE | ||
| 16 | 3.1 “Unauthorised Code” means any contaminant, virus, Trojan Horse, work, logic bomb or any other software routine or hardware components, including any codes or instructions designed to permit unauthorised access, to disable, modify, erase, damage, steal or usurp data or otherwise harm software, hardware or data, or to perform any such actions. | ||
| 17 | 3.2 “Software” means all software that forms part of or is shipped together with the Goods including but not limited to any utility software and diagnostics software. | ||
| 18 | 3.3 The Software, deliverables and any operating software supplied with the Goods will be free from all Unauthorised Code and nor will Supplier or any of its sub-vendors introduce any at any time. Further for this purpose, Supplier warrants that it has prior to the installation of the Software and operating software used the most comprehensive and up to date virus checker available. | ||
| 19 | 3.4 If, during or after the delivery and installation of a part of a System is completed, that part is discovered to contain or be affected by any Unauthorised Code and it is shown that this was the result of any default of or negligent act/omission of the Supplier or its employees, the Company may reject any such part of the System and/ or Software and the Supplier shall, at its own expense, immediately remove and recover all rejected parts of the System and/ or Software and provide replacements which are free of Unauthorised Code. | ||
| 20 | 3.5 The Supplier shall indemnify Company fully against all costs incurred by them in the course of or incidental to removing the Unauthorised Code and recovering any lost or damage data or software. | ||
| 21 | 4. RELIANCE | ||
| 22 | 4.1 The Supplier accepts that Company, inter alia, relies on the skill and judgement of the Supplier in the design, description, construction, quality, reliability and performance of the Goods to be provided and on the judgement and skill of the Supplier for any and all of the Services to be performed. | ||
| 23 | 4.2 In the event of the Supplier obtaining part(s) of the Goods to be supplied from a third party, the Supplier shall inform the Company in writing of the source of origin of the said part(s) of the Goods and, for avoidance of doubt, it is expressly declared that the Supplier shall remain fully liable for the said part(s) of the Goods and the consequences arising from the use of the said part(s) as if they were manufactured by the Supplier. | ||
| 24 | 5. Scope of Work (fixed-priced work) | ||
| 25 | 5.1 Overview | ||
| 26 | 5.1.1 This project (“Project”) is to implement a System or Solution to enhance its cybersecurity operational resilience and cybersecurity posture while maintaining strict adherence to regulatory standards. This project shall be implemented under a primary contract period of three (3) years, with an option to extend for up to two (2) additional years (3+1+1), subject to satisfactory performance and RWS approval. | ||
| 27 | 5.1.2 To support this initiative, RWS invites qualified Suppliers to propose solutions for the following: | ||
| 28 | 5.1.2.1 Deployment of Extended Detection and Response (XDR) Platform | ||
| 29 | The Project shall include the deployment of an Extended Detection and Response (XDR) Platform with advanced threat-detection, investigation, response, and vulnerability-shielding/virtual-patching capabilities. Coverage shall include servers, endpoints, laptops. Workstations, virtual desktops/machines, and containerized workloads. | ||
| 30 | For the avoidance of doubt, the overall XDR Platform solution shall comprise the following distinct components: | ||
| 31 | a) License / Software / Subscriptions: | ||
| 32 | Supply of the required XDR platform licenses, subscriptions, lightweight protection agents, data-collection connectors, integration modules, cloud-workload connectors, container security engines, vulnerability-management modules, and all supporting software necessary to provide full threat detection, investigation, response, and vulnerability shielding/virtual patching coverage across servers, endpoints, workstations, laptops, virtual desktop/machines, and containerized workloads. The solution shall support a cloud-native, unified telemetry architecture for seamless correlation and visibility across all workload types. Mandatory Protection Modules must cover the following | ||
| 33 | · Core EPP/EDR/XDR: Servers, Laptops, Workstations and virtual desktop/machines. | ||
| 34 | · Containers: Kubernetes, Azure Kubernetes Service (AKS), Alibaba Cloud Container Service for Kubernetes (ACK). | ||
| 35 | · Core Cloud Workloads: Protection for public cloud workloads and services, including Azure, and Microsoft M365 with runtime protection, posture evaluation, cloud-native threat detection, cross-cloud correlation and etc. | ||
| 36 | · Vulnerability Management: Vulnerability Assessment, Validation, Attack Simulation, Virtual Patching or Shielding. | ||
| 37 | · AI for Security: Automated response, chatbots, intelligent search and recommendations, incident sense making and meaning making. | ||
| 38 | · Integration with existing cybersecurity tools for automated and integrated threat defense for containment and eradication. | ||
| 39 | b) Professional Services (Implementation, Deployment and Migration): | ||
| 40 | One-time professional services for the design, planning, installation, configuration, testing, data migration, tuning, validation and commissioning of the complete XDR platform in accordance with Section 6 (Timeline, Documentation and Deliverables). The deployment approach shall minimize endpoint disruption and achieve rapid stabilization and operational readiness. | ||
| 41 | c) Managed Services (MXDR Day-2 Operations): | ||
| 42 | d) Ongoing 24 x 7 x 365 Managed Extended Detection and Response (MXDR) services, including continuous monitoring, automated and analyst guided investigation, real-time threat hunting, containment, eradication, AI-assisted incident analysis, storyline reconstruction, playbook execution and proactive security posture execution and improvements. The service shall leverage a cloud-first detection engine and unified event pipeline to ensure rapid triage and high-fidelity detections. | ||
| 43 | e) Support & Maintenance: | ||
| 44 | Warranty support and platform maintenance throughout the Contract Period of three (3) years, with up to two (2) additional one-year extensions (3+1+1). This includes platform enhancements, security updates, agent improvements, analytics/ML-model updates, content deployment, and continuous health monitoring of all components. | ||
| 45 | 5.1.2.2 (Optional) - Protection Modules | ||
| 46 | The following modules shall not be included in the base XDR proposal but shall be supported by the proposed solution architecture as optional add-on components that RWS may choose to activate at a later phase. Optional modules shall integrate natively with the XDR telemetry pipeline and console without requiring unnecessary duplication of agents. | ||
| 47 | 5.1.2.2.1 Additional Cloud Workloads Protection: | ||
| 48 | Protection for public cloud workloads and services, such as AliCloud, and other SaaS platforms with runtime protection, posture evaluation, cloud-native threat detection, and cross-cloud correlation. | ||
| 49 | 5.1.2.2.2 Mobile Protection: | ||
| 50 | Protection for enterprise mobile devices, including mobile threat defence, malware detection, application-risk inspection, unsafe network detection, and compliance enforcement. | ||
| 51 | 5.1.2.2.3 IoT/OT/Robotics Protection: | ||
| 52 | Threat detection and response for operational technology, industrial IoT, embedded devices, and robotics systems using specialized protocol awareness, asset discovery, anomaly detection, and behavioural analytics. | ||
| 53 | 5.1.2.2.4 Email Protection: | ||
| 54 | Comprehensive email threat detection and response including anti-phishing, anti-malware, URL/attachment detonation or sanitization, business email compromise (BEC) detection, impersonation analysis, and advanced email filtering. | ||
| 55 | 5.1.2.2.5 Network Protection: | ||
| 56 | Network detection and response (NDR) capabilities including deep packet inspection, network flow inspection, encrypted traffic analytics, lateral movement detection, device fingerprinting, and network behavioural analytics, all correlated into the XDR event pipeline. | ||
| 57 | 5.1.2.2.6 Identity Protection: | ||
| 58 | Identity Threat Detection and Response including monitoring for credential misuse, unauthorized privilege escalation, anomalous authentication behaviour, lateral movement, and identity-centric threats, with optional integration into IAM/IDP platforms for automated remediation. | ||
| 59 | 5.1.2.2.7 AI and Gen AI Security (Security for AI): | ||
| 60 | Security for AI applications including AI apps, GenAI models, CoPilot, ChatGPT, DeekSeek, and similar systems. Controls including monitoring of prompt input/output flows, AI-related data loss prevention, detection of malicious or unintended prompt manipulation, and governance of sensitive interactions with LLM-based services. | ||
| 61 | 5.1.2.3 Below is a high level reference point of view of the requirements. | ||
| 63 | 5.1.3 The required contract period shall be three (3) years, with an option to extend for up to two (2) additional years (3+1+1), subject to RWS approval. | ||
| 64 | The subscription period for software licenses and platform entitlements shall commence upon approval by the RWS Architecture Board (ARB) or upon RWS's written authorization, whichever is later. | ||
| 65 | The Managed Extended Detection and Response (MXDR) services shall commence upon successful platform Go-Live and formal acceptance by RWS IT. | ||
| 66 | 5.1.4 Services for the design, implementation, support and displacement of existing system or platform. | ||
| 67 | 5.1.5 The Supplier shall provide Managed Extended Detection and Response (MXDR) services to deliver continuous 24x7x365 cybersecurity surveillance, detection, and response operations, and to operate the maintain the proposed XDR platform. This scope covers Day-2 Managed XDR Operations, including continuous monitoring, investigation, containment support, threat hunting, and service reporting, specific to the new XDR platform implemented under this Project. | ||
| 68 | 5.1.6 The proposed solutions must align with recognized industry best practices, support both regulatory and internal compliance requirements, and strengthen RWS’s capabilities in threat detection, security monitoring and incident response. | ||
| 69 | 5.1.7 The Project will be carried out in Phases, as set out below: | ||
| 70 | 5.1.7.1 Phase 1: | ||
| 71 | 5.1.7.1.1 Architecture and Design | ||
| 72 | 5.1.7.1.2 Platform Deployment | ||
| 73 | 5.1.7.1.3 Integrations | ||
| 74 | 5.1.7.2 Phase 2: | ||
| 75 | 5.1.7.2.1 Rollout Planning | ||
| 76 | 5.1.7.2.2 Migration and Onboarding (Including removal of old solution) | ||
| 77 | 5.1.7.2.3 Use Case Development/ Configuration Fine Tuning | ||
| 78 | 5.1.7.2.4 Dashboard or Report Building | ||
| 79 | 5.1.7.3 Phase 3: | ||
| 80 | 5.1.7.3.1 24x7x365 Managed Extended Detection and Response (MXDR) / Security Operations Centre | ||
| 81 | 5.2 Project Initiation/Kick off & Project Management | ||
| 82 | 5.2.1 The project will be initiated with a kick-off meeting along with the project stakeholders and key project members to align project scope, timeline, roles and responsibilities. | ||
| 83 | 5.2.2 The Supplier will appoint a Project Manager based in Singapore as the single point of contact for the overall project. The Project Manager shall report to the Company’s appointed representative. | ||
| 84 | 5.2.3 The Supplier’s Project Manager shall work with the Company’s appointed Project Manager and representative(s) to manage the Project, including but not limited to: | ||
| 85 | 5.2.3.1 Identifying project resource stakeholders, | ||
| 86 | 5.2.3.2 Developing the project charter, | ||
| 87 | 5.2.3.3 Planning and conducting project kick off meeting | ||
| 88 | 5.2.3.4 Planning and conducting periodic project meetings for steering committee and working committee | ||
| 89 | 5.2.3.5 Developing detailed project plan which includes but is not limited to: | ||
| 90 | 5.2.3.5.1 Project timeline & key milestones | ||
| 91 | 5.2.3.5.2 Roles and responsibilities for all resources working on the project | ||
| 92 | 5.2.3.5.3 List of project assumptions, risks and issues | ||
| 93 | 5.2.3.5.4 List of project changes requests | ||
| 94 | 5.2.3.5.5 Project deliverables | ||
| 95 | 5.2.3.5.6 Deployment strategy and approach to minimise impact to business operations | ||
| 96 | 5.2.3.5.7 Design and architecture review with the Company’s appointed representative(s). | ||
| 97 | 5.2.3.5.8 Post implementation review | ||
| 98 | 5.3 Project Personnel | ||
| 99 | 5.3.1 The Supplier shall ensure that the personnel assigned to the Project are appropriately qualified, skilled, and experienced in the roles that have been allocated to them. | ||
| 100 | 5.3.2 The Supplier shall provide the Company with at least seven (7) days’ prior written notice of any planned leave of absence by key personnel exceeding five (5) consecutive working days. For unplanned or emergency leave, the Supplier shall notify the Company as soon as practicable. The Supplier shall ensure that suitable interim coverage is arranged to maintain service continuity, subject to the Company’s prior written approval under Section 5.3.6, if required. | ||
| 101 | 5.3.3 Except as provided in Section 5.3.4, the Supplier shall retain the assigned personnel for the duration of the Project, unless they have an extended illness or are no longer contracted or employed by the Supplier. The Supplier shall give the Company at least fourteen (14) days’ prior written notice before any of the personnel are removed from the Project. | ||
| 102 | 5.3.4 The Company may require the Supplier to remove any personnel engaged for the Services, including the Project Manager, who in the reasonable opinion of the Company: | ||
| 103 | 5.3.4.1 has engaged in any misconduct, | ||
| 104 | 5.3.4.2 is incompetent, negligent, or unsatisfactory in the performance of his duties, | ||
| 105 | 5.3.4.3 fails to conform with any provisions of this LOA, or | ||
| 106 | 5.3.4.4 acts in a manner prejudicial to safety, health, or the reputation of the Company. | ||
| 107 | 5.3.5 If any personnel are removed from the Project pursuant to Sections 5.3.3 or 5.3.4, the Supplier shall appoint a suitable replacement within fourteen (14) days from the date of the personnel’s removal from the Project. | ||
| 108 | 5.3.6 Before assigning any personnel to the Project, including replacements under Sections 5.3.3 or 5.3.4, the Supplier shall submit their qualifications, experience, and role responsibilities for the Company’s review. The Company reserves the right to interview and approve or reject any proposed personnel, regardless of technical qualifications. The Supplier shall not assign any personnel to the Project without the Company’s prior written approval, which shall not be unreasonably withheld. | ||
| 109 | 5.3.7 For any replacement under Sections 5.3.3 or 5.3.4, the Supplier shall ensure adequate knowledge transfer and training to minimize disruption to the Project. | ||
| 110 | 5.3.8 For the purposes of this LOA, ‘key personnel’ shall include, but not be limited to, the Project Manager, Lead Developer, and any other roles critical to the delivery of the Services as identified by the Company. | ||
| 111 | 5.4 Requirements | ||
| 112 | 5.4.1 The Supplier will conduct detailed requirement gathering workshops with the Company’s appointed representative(s) and/or third party, to: | ||
| 113 | 5.4.1.1 Produce solution and design services for implementation of the System in accordance with the requirements as set out in this LOA; | ||
| 114 | 5.4.1.2 Provide the requirement deliverables as set out in Section 6 of this Appendix B1; and | ||
| 115 | 5.4.1.3 Ensure the System meets the expectations and purpose of this Project. | ||
| 116 | 5.4.1.4 Ensure the System meets the functional requirements as set out in Appendix E | ||
| 117 | 5.4.2 Technical requirements of the System or Solution | ||
| 118 | 5.4.2.1 General Technical Requirements | ||
| 119 | 5.4.2.1.1 Agent & Management | ||
| 120 | 5.4.2.1.1.1 The solution shall provide a single lightweight endpoint agent and single user interface for management that delivers all prevention and protection functions or modules without requiring on-premises management servers. | ||
| 121 | 5.4.2.1.1.2 The solution shall support granular access control on role-based access control (RBAC) and user groups to limit features and access. It shall also support report generation for user access reviews and privileged activities reviews. | ||
| 122 | 5.4.2.1.1.3 The solution shall offer RESTful API for custom integration via authentication API. | ||
| 123 | 5.4.2.1.1.4 The solution shall support the creation and management of customized watchlists and Indicators of Compromise (IOCs) for proactive threat detection. This capability must allow administrators to define and monitor specific artifacts including: | ||
| 124 | · Domains | ||
| 125 | · IP addresses | ||
| 126 | · SHA1/SHA2 file hashes | ||
| 127 | · Registry keys | ||
| 128 | · Filenames | ||
| 129 | 5.4.2.1.1.5 These custom rules must be fully configurable and integrated into the agent’s detection engine to enable real-time monitoring and alerting based on organization-specific threat intelligence. | ||
| 130 | 5.4.2.1.1.6 The solution shall support silent, unattended installation and automated removal through standard enterprise tools such as Intune, SCCM, or GPO. | ||
| 131 | 5.4.2.1.1.7 The solution agent shall be able to be installed, upgraded, or uninstalled from within the management platform interface. | ||
| 132 | 5.4.2.1.1.8 The solution agent shall be persistent to ensure the host is protected even if an attacker attempts to reboot the host. | ||
| 133 | 5.4.2.1.1.9 The solution shall provide runtime protection for all running application processes through use of unique and non-contiguous memory addressing space for each running application process. In addition, they shall detect and stop any attempt by any running application process to read beyond its allocated memory addressing space (i.e. in a buffer-overflow attack). | ||
| 134 | 5.4.2.1.1.10 The solution shall support in-place upgrades using a configurable staggered rollout ring strategy, enabling phased deployment across defined user or device groups. Each rollout ring must be customizable in terms of timing, scope, and criteria for progression to the next ring. Additionally, the solution must include: | ||
| 135 | · Automatic rollback mechanisms in the event of upgrade failure, ensuring system stability and continuity. | For certain critical, widespread issues caused by Windows updates, Microsoft can use the Windows Update infrastructure to activate a Known Issue Rollback (KIR) to disable the problematic change remotely and automatically on affected consumer devices. This is a Microsoft-driven process, not a client-side triggerable one for MDE-specific updates. | |
| 136 | · Agent self-healing capabilities to detect and repair corrupted or malfunctioning components autonomously. | ||
| 137 | · Full execution of the upgrade, rollback, and healing processes without any manual intervention, ensuring a seamless and resilient upgrade experience. | ||
| 138 | 5.4.2.1.1.11 The solution shall support phased deployment strategy where updates or changes are released in waves or "rings" to different groups of users or systems. The solution shall support ring representation during rollout process: | ||
| 139 | · Ring 0: Internal testers or Cybersecurity team (early adopters) | ||
| 140 | · Ring 1: Power users or pilot groups | ||
| 141 | · Ring 2: Broader user base | ||
| 142 | · Ring 3: General availability (everyone) | ||
| 143 | 5.4.2.1.1.12 The rollout rings shall be customizable and support the following: | ||
| 144 | · Who is in each ring | ||
| 145 | · When each ring receives the update | ||
| 146 | · What conditions must be met before progressing to the next ring | ||
| 147 | 5.4.2.1.1.13 The solution and agent must implement anti-tampering and self-healing capabilities that prevent attackers – even those with administrator privileges or remote shell access – from disabling or bypassing protection components. Any attempt to terminate, unload, modify, or uninstall security agent must be blocked, logged, and trigger an immediate high-severity alert. | ||
| 148 | 5.4.2.1.1.14 The solution agent shall operate in co-existence with other endpoint controls, such as other Endpoint Detection and Response (EDR) or Data Loss Prevention (DLP) solution and provide documented guidance for conflict management, exclusion or whitelisting. | ||
| 149 | 5.4.2.1.1.15 The solution shall be able to support all major Windows versions and major Linux versions. | ||
| 150 | 5.4.2.1.1.16 The solution shall not inject any code into running processes under any circumstances. | ||
| 151 | 5.4.2.1.1.17 The solution must be capable of providing full endpoint protection even when the device is disconnected from the Internet or the central management platform. Its core protection capabilities—including threat detection, prevention, and remediation—must remain functionally effective in offline scenarios, with no significant degradation in security performance or coverage. | ||
| 152 | 5.4.2.1.1.18 The solution shall provide real-time protection for all active application processes by enforcing the use of unique and non-contiguous memory address spaces for each process. This isolation must prevent unauthorized memory access between processes. | ||
| 153 | 5.4.2.1.1.19 Furthermore, the solution must be capable of detecting and blocking any attempt by a running application to access memory beyond its allocated boundaries, such as in buffer overflow attacks. These protections must operate continuously and autonomously, ensuring robust runtime security without manual intervention. | ||
| 154 | 5.4.2.1.1.20 The solution agent shall provide the capability to isolate an endpoint from the network, effectively containing potential threats while maintaining secure remote access for forensic investigation and analysis. This isolation must be enforceable remotely and allow authorized personnel to perform diagnostics and evidence collection without reintroducing risk to the broader environment. | ||
| 155 | 5.4.2.1.1.21 The solution shall support a comprehensive set of automated and remote remediation actions to effectively respond to detected threats. These actions must include: | ||
| 156 | · Host isolation to contain compromised endpoints | ||
| 157 | · Process termination for malicious or suspicious activities | ||
| 158 | · User account disablement and re-enablement | ||
| 159 | · Thread suspension to halt harmful execution paths | ||
| 160 | · Remote command execution for investigative or corrective tasks | ||
| 161 | · Remote data collection for forensic analysis | ||
| 162 | · Removal of suspicious files, processes, and threads | ||
| 163 | All remediation actions must be executable without manual intervention, ensuring rapid and secure threat response. | ||
| 164 | 5.4.2.2 Agent Deployment and Architecture Requirements | ||
| 165 | 5.4.2.2.1 The solution shall utilize a single agent to support all required endpoint, servers, workstations, virtual desktops, machines, and containers. | ||
| 166 | 5.4.2.2.2 The solution shall not depend on multiple agents, separate installers, or additional components to enable any required protection, detection or telemetry functions. | ||
| 167 | 5.4.2.2.3 A single universal installer must be provided and must be applicable across all supported operating systems and workload types. | ||
| 168 | 5.4.2.2.4 Full functionality must be delivered by the same agent on endpoints, servers, workstations, virtual desktops, machines, and containers, without requiring alternative builds or reduced-capability modes. | ||
| 169 | 5.4.2.2.5 The solution must support efficient, scalable deployment without dependency sequencing, multi-stage installations workflow, or installation of multiple agent components. | ||
| 170 | 5.4.2.3 Endpoint Protection Platform (EPP) Technical Requirements | ||
| 171 | 5.4.2.3.1 Policy & Administration | ||
| 172 | 5.4.2.3.1.1 The solution shall allow logical segmentation of devices using groups or tags for targeted policy application and enforcement. | ||
| 173 | 5.4.2.3.1.2 The solution shall provide policy versioning with cloning, comparison, rollback, and full change history audit trail. | ||
| 174 | 5.4.2.3.1.3 The solution shall support segregation-of-duties workflows to ensure operational and security responsibilities are clearly separated. For example: | ||
| 175 | · IT staff shall be permitted to perform actions such as deployment and uninstallation of agents or components. | ||
| 176 | · Security staff shall retain exclusive authority to approve quarantine restores and other sensitive security decisions. | ||
| 177 | 5.4.2.3.1.4 This role-based control must be enforceable through policy configuration and audit logging to maintain compliance and accountability. The solution shall provide a test or “monitor-only” or “detection” mode for new rules to validate policies before full enforcement. | ||
| 178 | 5.4.2.3.2 Threat Prevention & Control | ||
| 179 | 5.4.2.3.2.1 The solution shall deliver real-time malware prevention using signatures, machine learning, and behavioural models, with full functionality even when offline. | ||
| 180 | 5.4.2.3.2.2 The solution shall block ransomware behaviours such as rapid encryption, mass renaming, or deletion, and provide one-click restore integration where operating systems support snapshotting. | ||
| 181 | 5.4.2.3.2.3 The solution shall be capable of detecting and remediating advanced and evasive threats, including but not limited to: | ||
| 182 | · Fileless attacks | ||
| 183 | · Zero-day exploits | ||
| 184 | · Rootkits | ||
| 185 | · Keyloggers | ||
| 186 | · Memory-based exploits | ||
| 187 | · Ransomware | ||
| 188 | · Suspicious behaviours and anomalies | ||
| 189 | · Malicious macros | ||
| 190 | · Process, DLL, and shellcode injection attempts | ||
| 191 | · Cryptocurrency mining activities | ||
| 192 | Detection must be real-time and behaviour-based, with automated remediation actions to neutralize threats and restore system integrity without manual intervention. | ||
| 193 | 5.4.2.3.2.4 The solution shall prevent memory-based exploits, including return-oriented programming, heap spray, and shellcode injection, without relying on signatures. | ||
| 194 | 5.4.2.3.2.5 The solution shall prevent abuse of macros and scripts (for example, Office macros or wscript/jscript) based on configurable policies. | ||
| 195 | 5.4.2.3.2.6 The solution shall detect and stop fileless techniques and the abuse of living-off-the-land binaries such as PowerShell, certutil, regsvr32, or mshta. | ||
| 196 | 5.4.2.3.2.7 The solution shall provide application control based on hash, certificate, path, publisher, or reputation, with an optional lockdown mode where only allow-listed binaries may execute. | ||
| 197 | 5.4.2.3.2.8 The solution shall enforce device control for USB, Bluetooth, and external storage, supporting block, read-only, shadow copy, and USB reputation or adaptive policies. | ||
| 198 | 5.4.2.3.2.9 The solution shall include browser and network protection, such as phishing defence, malicious URL blocking, DNS tunnelling detection, and command-and-control callback prevention. | ||
| 199 | 5.4.2.3.2.10 The solution shall utilize the agent-based firewall to enforce host-level network rules that are policy-driven, auditable, and accessible via API. | ||
| 200 | 5.4.2.3.2.11 The solution shall provide exploit shielding or virtual vulnerability patching capabilities at the endpoint level to protect against both known CVEs and zero-day vulnerabilities. This protection must be effective in scenarios where official patches are: | ||
| 201 | · Not yet available | ||
| 202 | · Cannot be applied immediately due to operational constraints | ||
| 203 | The shielding mechanism must proactively block exploit attempts by simulating patch behaviour, ensuring continued endpoint security until permanent remediation is possible. | ||
| 204 | 5.4.2.3.3 Performance & Reliability | ||
| 205 | 5.4.2.3.3.1 The solution shall maintain minimal performance impact, with an average CPU usage of less than or equal to 5% and idle RAM consumption of no more than 250 MB on reference hardware. | CPU limit is possible for scheduled scans. However, Memory usage is dynamic and depends on the complexity of files being scanned and the amount of system memory available. | |
| 206 | 5.4.2.3.3.2 The solution shall adapt to unfavourable conditions such as low battery or poor network by deferring heavy tasks, while continuing to queue essential telemetry when offline. | ||
| 207 | 5.4.2.3.3.3 The solution shall support both persistent and non-persistent virtual desktop infrastructure (VDI) with consistent identity recognition and clone-safe identifiers, and support server workloads without loss of features. | ||
| 208 | 5.4.2.3.3.4 The solution shall enforce performance guardrails with hard CPU and RAM ceilings and provide an emergency safe mode to prevent business disruption if misconfigurations occur. | CPU limit is possible for scheduled scans. However, Memory usage is dynamic and depends on the complexity of files being scanned and the amount of system memory available. | |
| 209 | 5.4.2.3.4 Telemetry & Reporting | ||
| 210 | 5.4.2.3.4.1 The solution shall generate structured JSON prevention events that include file path, hash, signer, user, process, detection engine, and policy ID. | ||
| 211 | 5.4.2.3.4.2 The solution shall export event data through secure and standardized methods such as Syslog over TLS, CEF/LEEF, REST APIs, and webhooks, with automatic retries in case of transmission failure. | ||
| 212 | 5.4.2.3.4.3 The solution shall provide a published field dictionary for prevention events, along with SIEM mapping guides. | ||
| 213 | 5.4.2.3.4.4 The solution shall deliver dashboards that highlight endpoint posture, such as coverage gaps, outdated content, non-compliant hosts, and risky applications. | ||
| 214 | 5.4.2.3.4.5 The solution shall generate compliance reports aligned to frameworks such as ISO, PCI, and PDPA. | ||
| 215 | 5.4.2.3.4.6 The solution shall raise tamper alerts locally and centrally, surface endpoint risk scores for Zero-Trust integrations, and enrich block logs with threat intelligence context such as indicator age and confidence. | ||
| 216 | 5.4.2.3.5 Operational Tools | ||
| 217 | 5.4.2.3.5.1 The solution shall provide secure local quarantine with administrator-controlled restore and allow policy-based auto-isolation triggers for malicious behaviours. | ||
| 218 | 5.4.2.3.5.2 The solution shall include troubleshooting tools such as diagnostic log collection, agent repair workflows, and API-accessible diagnostics. | ||
| 219 | 5.4.2.3.5.3 The solution shall support the use of offline update packages and enable secure, signed air-gap workflows through removable media or internal repositories. | ||
| 220 | 5.4.2.3.5.4 The solution shall publish detailed release notes with every content or engine update, including fixes, new detections, and known limitations. | ||
| 221 | 5.4.2.3.5.5 The solution shall allow safe file or metadata submission for vendor analysis with privacy controls and support classification tuning for potentially unwanted applications. | ||
| 222 | 5.4.2.3.5.6 The solution shall enforce immutable audit logs of agent and administrative actions, retaining at least 90 days of change history. | ||
| 223 | 5.4.2.3.5.7 The solution shall support self-service on-demand scanning enabling users to manually initiate scans of specific files, folders or full drives including removable media (e.g., USB storage). Scans results must be reported both locally to users and centrally to the management console. | ||
| 224 | 5.4.2.4 Endpoint Detection and Response (EDR) Technical Requirements | ||
| 225 | 5.4.2.4.1 Telemetry Collection | ||
| 226 | 5.4.2.4.1.1 The solution agent shall be capable of acquiring a wide range of system artifacts from Windows endpoints to support forensic investigation, threat hunting, and incident response. These artifacts shall include, but not be limited to: | ||
| 227 | · System Information (OS version, hostname, uptime) | ||
| 228 | · File System Metadata and Access History | ||
| 229 | · Drivers and Kernel Modules | ||
| 230 | · Kernel Hook Detection | ||
| 231 | · Persistence Mechanisms (autoruns, scheduled tasks, services) | ||
| 232 | · Registry Keys and Values | ||
| 233 | · Event Logs (System, Security, Application) | ||
| 234 | · Running Processes and Threads | ||
| 235 | · Browser Cache and History | ||
| 236 | · Scheduled Tasks and Cron Jobs | ||
| 237 | · Network Configuration, Connections, and Traffic Metadata | ||
| 238 | · Active and Inactive Services | ||
| 239 | · Agent-Generated Events and Logs | ||
| 240 | · DLLs and Loaded Modules | ||
| 241 | · User Accounts and Privileges | ||
| 242 | · Clipboard Contents | ||
| 243 | · PowerShell and Command Line Execution History | ||
| 244 | · WMI Queries and Scripts | ||
| 245 | · Prefetch Files | ||
| 246 | · Shim Cache (AppCompat) | ||
| 247 | · MFT and USN Journal | ||
| 248 | · Memory Dumps and Pagefile Analysis | ||
| 249 | · DNS Cache and Resolver History | ||
| 250 | · ARP Table and Routing Information | ||
| 251 | · SMB Sessions and Shares | ||
| 252 | · Remote Desktop Session History | ||
| 253 | · Installed Applications and Software Inventory | ||
| 254 | · Cloud Integration Artifacts: | ||
| 255 | ü Microsoft 365 activity logs (e.g., Outlook, OneDrive, Teams) | ||
| 256 | ü Azure AD sign-in and audit logs | ||
| 257 | ü Cloud sync status and metadata | ||
| 258 | ü Token and credential usage history | ||
| 259 | ü Cloud storage access patterns | ||
| 260 | 5.4.2.4.1.2 The solution agent shall be capable of acquiring system artifacts from Linux endpoints to support forensic analysis and threat detection. These artifacts shall include, but not be limited to: | ||
| 261 | · System Information (Kernel version, distro, uptime, hostname) | ||
| 262 | · File System Metadata and Access History | ||
| 263 | · Running Processes and Threads | ||
| 264 | · Scheduled Tasks (cron jobs, systemd timers) | ||
| 265 | · Network Configuration, Connections, and Traffic Metadata | ||
| 266 | · Active and Inactive Services (systemd, init.d) | ||
| 267 | · User Accounts and Groups | ||
| 268 | · Shell History and Execution Logs | ||
| 269 | · Loaded Kernel Modules | ||
| 270 | · System Logs (/var/log, journalctl) | ||
| 271 | · SSH Configuration and Session History | ||
| 272 | · Installed Packages and Software Inventory | ||
| 273 | · Environment Variables | ||
| 274 | · Open Ports and Listening Services | ||
| 275 | · DNS Configuration and Resolver History | ||
| 276 | · ARP Table and Routing Information | ||
| 277 | · Memory Dumps and Swap Usage | ||
| 278 | · Audit Logs (auditd) | ||
| 279 | · SELinux/AppArmor Policies and Violations | ||
| 280 | · Container Runtime Metadata (Docker, Podman, etc.) | ||
| 281 | · Cloud Integration Artifacts: | ||
| 282 | ü Cloud CLI usage history (e.g., AWS CLI, Azure CLI, GCP SDK) | ||
| 283 | ü Cloud credential files and token metadata | ||
| 284 | ü Cloud sync agents and configuration files | ||
| 285 | ü Metadata from cloud-mounted file systems (e.g., S3, Azure Blob) | ||
| 286 | ü Logs from cloud-based monitoring agents | ||
| 287 | 5.4.2.4.1.3 The solution shall collect detailed process telemetry, including start and stop events, command-line arguments, parent and child relationships, signer, hash, module loads, and integrity levels with precise timestamps. | ||
| 288 | 5.4.2.4.1.4 The solution shall collect file telemetry covering creation, modification, and deletion, including file path, hash, and initiating process, with support for alternate data streams where applicable. | ||
| 289 | 5.4.2.4.1.5 The solution shall collect persistence-related changes such as new or modified services, drivers, scheduled tasks, and registry or plist modifications, while retaining both before-and-after values. | ||
| 290 | 5.4.2.4.1.6 The solution shall collect network telemetry, including connection and listening events, along with associated process, protocol, ports, bytes transferred, and communication direction. | ||
| 291 | 5.4.2.4.1.7 The solution shall collect DNS telemetry, mapping query and response data to the originating process. | ||
| 292 | 5.4.2.4.1.8 The solution shall capture authentication events including local and remote logons, session creation, source, and result codes. | ||
| 293 | 5.4.2.4.1.9 The solution shall collect telemetry from interpreters and scripts (such as PowerShell, AMSI, wscript, or cscript) where supported by the operating system. | ||
| 294 | 5.4.2.4.1.10 The solution shall provide in-memory and injection indicators, such as reflective module loads and thread injection signatures, wherever the operating system allows. | ||
| 295 | 5.4.2.4.1.11 The solution shall locally buffer telemetry during network outages and ensure orderly data backfill once connectivity is restored. | ||
| 296 | 5.4.2.4.1.12 The solution shall retain telemetry in hot searchable storage for a minimum of 90 days. | ||
| 297 | 5.4.2.4.2 Detection and Analysis | ||
| 298 | 5.4.2.4.2.1 The solution shall leverage behavioural analytics, machine learning, and telemetry correlation to detect and respond to sophisticated APT techniques. Detection capabilities must include, but not be limited to: | ||
| 299 | 5.4.2.4.2.1.1 Living-off-the-Land (LOTL) Techniques | ||
| 300 | · Abuse of legitimate tools (e.g., PowerShell, WMI, PsExec, CertUtil, Rundll32) | ||
| 301 | · Fileless execution and script-based attacks | ||
| 302 | · Use of native OS utilities for lateral movement, data staging, or exfiltration | ||
| 303 | 5.4.2.4.2.1.2 Multi-Stage Attack Chains | ||
| 304 | · Detection of attack progression from initial access to persistence, privilege escalation, lateral movement, and exfiltration | ||
| 305 | · Correlation of events across time and endpoints to identify stealthy campaigns | ||
| 306 | 5.4.2.4.2.1.3 Credential Access and Abuse | ||
| 307 | · Credential dumping (e.g., LSASS memory access, Mimikatz) | ||
| 308 | · Pass-the-Hash, Pass-the-Ticket, and Kerberoasting | ||
| 309 | · Abuse of cached credentials or token theft | ||
| 310 | 5.4.2.4.2.1.4 Persistence Mechanisms | ||
| 311 | · Registry and scheduled task manipulation | ||
| 312 | · Service creation/modification | ||
| 313 | · DLL sideloading and hijacking | ||
| 314 | · WMI event subscriptions | ||
| 315 | 5.4.2.4.2.1.5 Privilege Escalation | ||
| 316 | · Exploitation of vulnerable drivers or services | ||
| 317 | · Bypassing User Account Control (UAC) | ||
| 318 | · Token manipulation and impersonation | ||
| 319 | 5.4.2.4.2.1.6 Lateral Movement | ||
| 320 | · Remote service creation | ||
| 321 | · SMB/NTLM relay attacks | ||
| 322 | · Remote desktop protocol (RDP) abuse | ||
| 323 | · Remote WMI or PowerShell execution | ||
| 324 | 5.4.2.4.2.1.7 Defence Evasion | ||
| 325 | · Obfuscated or encrypted payloads | ||
| 326 | · Disabling security tools or logging | ||
| 327 | · Use of signed binaries for malicious purposes | ||
| 328 | · Time-based execution delays | ||
| 329 | 5.4.2.4.2.1.8 Command and Control (C2) Detection | ||
| 330 | · Beaconing behaviour and periodic callbacks | ||
| 331 | · Use of DNS tunnelling, HTTPS, or cloud services for C2 | ||
| 332 | · Detection of anomalous outbound traffic patterns | ||
| 333 | 5.4.2.4.2.1.9 Data Collection and Exfiltration | ||
| 334 | · Staging of sensitive files | ||
| 335 | · Compression and encryption of data | ||
| 336 | · Use of cloud storage or covert channels for exfiltration | ||
| 337 | 5.4.2.4.2.1.10 Threat Simulation and Emulation Detection | ||
| 338 | · Identification of red team tools (e.g., Cobalt Strike, Metasploit, Empire) | ||
| 339 | · Detection of known TTPs mapped to MITRE ATT&CK framework | ||
| 340 | 5.4.2.4.2.2 Detection must be real-time, context-aware, and capable of correlating telemetry across endpoints to surface complex attack sequences that traditional signature-based methods may miss. | ||
| 341 | 5.4.2.4.2.3 The solution shall detect ransomware across all attack stages, including initial access, staging, shadow copy deletion, and encryption activity. | ||
| 342 | 5.4.2.4.2.4 The solution shall detect persistence and privilege-escalation techniques with reliable context. | ||
| 343 | 5.4.2.4.2.5 The solution shall support real-time and historical matching of indicators of compromise (IOC), indicators of attack (IOAs), and YARA rules. | ||
| 344 | 5.4.2.4.2.6 The solution shall support retrospective hunting by re-evaluating historical telemetry when new threat intelligence becomes available. | ||
| 345 | 5.4.2.4.2.7 The solution shall automatically map all detections to MITRE ATT&CK techniques and sub-techniques. | ||
| 346 | 5.4.2.4.2.8 The solution shall compute dynamic risk scores for hosts, users, and processes based on observed behaviours, prevalence, and asset criticality. | ||
| 347 | 5.4.2.4.3 Investigation & Hunting | ||
| 348 | 5.4.2.4.3.1 The solution shall provide visual process trees and timelines to reconstruct incidents from initiation to resolution. | ||
| 349 | 5.4.2.4.3.2 The solution shall allow investigation pivots across entities such as host, user, file hash, domain, and IP address within a single interface. | ||
| 350 | 5.4.2.4.3.3 The solution shall allow threat hunting to be saved and scheduled, and automatically generate alerts when matches are found. | ||
| 351 | 5.4.2.4.3.4 The solution shall include prebuilt hunting queries for common adversary behaviours such as beaconing, credential dumping, and persistence techniques. | ||
| 352 | 5.4.2.4.3.5 The solution shall provide case management features, including notes, tags, attachments, task assignments, SLA tracking, and linking of related cases. | ||
| 353 | 5.4.2.4.3.6 The solution shall support remote investigation capabilities, including the export of forensic bundles (files, logs, and memory snapshots) with chain-of-custody integrity. | ||
| 354 | 5.4.2.4.3.7 The solution shall support API-driven hunting and investigation workflows to enable automation and integration with third-party systems. | ||
| 355 | 5.4.2.4.4 Response & Containment | ||
| 356 | 5.4.2.4.4.1 The solution shall support remote network isolation of endpoints, with options for full isolation or egress-allowlists, and allow timed or manual release. | ||
| 357 | 5.4.2.4.4.2 The solution shall allow remote process termination and file quarantine or restore, maintaining full audit trails for all actions. | ||
| 358 | 5.4.2.4.4.3 The solution shall allow the enforcement of block lists based on file hash or signature, preventing future executions of known malicious binaries. | ||
| 359 | 5.4.2.4.4.4 The solution shall support scripted remediation tasks such as removing persistence mechanisms or restoring system configurations, with a dry-run mode for validation prior to enforcement. | ||
| 360 | 5.4.2.4.4.5 The solution shall provide ransomware rollback and file restoration capabilities where supported by operating system journaling or snapshots features. | ||
| 361 | 5.4.2.4.4.6 The solution shall provide ransomware rollback and file restoration capabilities, leveraging operating system journaling, snapshot features, or equivalent mechanisms where supported. This functionality must: | ||
| 362 | · Automatically restore files encrypted or deleted by ransomware attacks | ||
| 363 | · Utilize native OS features such as Windows Volume Shadow Copy, macOS Time Machine, or Linux LVM snapshots | ||
| 364 | · Ensure rollback is secure, verifiable, and tamper-resistant | ||
| 365 | · Operate with minimal disruption to the user or system | ||
| 366 | · Be integrated with detection logic to trigger rollback only upon confirmed malicious activity | ||
| 367 | · Retain rollback points for a configurable duration to support post-incident recovery | ||
| 368 | 5.4.2.4.4.7 The solution shall enable secure live response through a remote shell, controlled file and memory collection, and role-based access approvals. | ||
| 369 | 5.4.2.4.4.8 The solution shall immutably log all response actions, capturing the actor’s identity, timestamp, target, and the outcome of each action. | ||
| 370 | 5.4.2.4.4.9 The solution must support temporary isolation exceptions for clustered or mission-critical systems, with automatic reversion to standard settings. | ||
| 371 | 5.4.2.4.4.10 The solution shall apply server-aware containment strategies to avoid outages in clustered or high-availability environments. | ||
| 372 | 5.4.2.4.4.11 The solution must support read-only data collection from operational technology (OT) and industrial control systems (ICS) endpoints, without initiating any active response actions. | ||
| 373 | 5.4.2.4.5 Performance & Scalability | ||
| 374 | 5.4.2.4.5.1 The solution must be capable of scaling to support a minimum of 10,000 endpoints per tenant, while maintaining consistent performance as the number of endpoints increases. | ||
| 375 | 5.4.2.4.5.2 The solution shall achieve median ingest latency of less than 60 seconds from endpoint event to searchable record. | Armor cannot guarantee Microsoft platform SLOs | |
| 376 | 5.4.2.4.5.3 The solution must successfully execute 95% of isolation commands on online endpoints within 30 seconds. | Armor cannot guarantee Microsoft platform SLOs | |
| 377 | 5.4.2.4.5.4 The solution shall complete 95% of standard seven-day queries in under five seconds, based on the defined ingestion volume. | Armor cannot guarantee Microsoft platform SLOs | |
| 378 | 5.4.2.4.5.5 The solution shall maintain an API uptime of at least 99.9% and a data pipeline availability of 99.99%, with published Service Level Objectives (SLOs). | Armor cannot guarantee Microsoft platform SLOs | |
| 379 | 5.4.2.4.5.6 The solution shall maintain backward compatibility for endpoint agents for a minimum of 24 months, with a clearly documented deprecation policy. | Microsoft doesn't provide a fixed period for Defender support (like 24-months), however, Microsoft will inform through various channels (in-product, emails, documentations and blogposts) about O/S that are reaching EOS. In such circumstances where Windows O/S are EOS, Defender XDR/MDE will still provide protection for those O/S, including product updates. For reference, Microsoft recently announced a new MDE deployment tool for Windows 7 SP1 and Windows Server 2008 R2 and Windows Server 2012 that continue to provide advanced protection for these O/S. | |
| 380 | 5.4.2.4.6 Noise Reduction & Case Handling | ||
| 381 | 5.4.2.4.6.1 The solution must include workflows for reducing alert noise, such as suppression rules with configurable expiration and review options, and must provide precision and recall metrics to evaluate detection accuracy. | ||
| 382 | 5.4.2.4.6.2 The solution shall support legal hold and evidence retention policies that are configurable on a per-case basis. | ||
| 383 | 5.4.2.4.6.3 The solution shall ensure secure tenant data segregation and evidence handling in multi-tenant cloud environments. | ||
| 384 | 5.4.2.4.6.4 The solution shall publish a telemetry schema with field definitions, data types, units, and time zones, along with versioning and deprecation notices. | ||
| 385 | 5.4.2.4.6.5 The solution shall detect endpoint identity spoofing (such as hostname or user tampering) and flag telemetry anomalies. | ||
| 386 | 5.4.2.4.6.6 The solution shall baseline per-host process behaviours to aid anomaly scoring, without overlapping with UEBA features. | ||
| 387 | 5.4.2.4.6.7 The solution shall disclose query concurrency limits and rate limits and shall queue and estimate completion time for large hunts. | ||
| 388 | 5.4.2.4.6.8 The solution must enforce the use of signed remediation scripts, incorporate a code review process and track the origin and history of each script. | ||
| 389 | 5.4.2.4.6.9 The solution must support memory capture where technically feasible, ensuring encryption at the point of collection, integrity verification through hashing, and data segmentation via chunking. | ||
| 390 | 5.4.2.4.6.10 The solution shall allow registry or plist backup and restore before executing destructive remediation actions. | ||
| 391 | 5.4.2.4.6.11 The solution must support the use of hash-based cataloguing of evidence artifacts across cases to enhance storage efficiency and accelerate investigations. | ||
| 392 | 5.4.2.4.6.12 The solution must automatically associate related cases on shared indicators or stages in the kill chain and visually group them into clusters for streamlined analysis. | ||
| 393 | 5.4.2.4.6.13 The solution shall provide alert deduplication heuristics configurable per rule, using time windows and similarity thresholds. | ||
| 394 | 5.4.2.4.6.14 The solution shall surface behavioural anomalies unique to a host, such as rare service creation or unusual autorun entries. | ||
| 395 | 5.4.2.4.6.15 The solution shall automate endpoint tagging (e.g., “Compromised” or “Needs Patch”) based on detection outcomes with time-to-live expiry. | ||
| 396 | 5.4.2.4.6.16 The solution shall support content lifecycle management with development, test, and production spaces, allowing staged promotion and rollback of detection rules. | ||
| 397 | 5.4.2.4.6.17 The solution shall provide a vendor false-positive appeal process with SLAs for resolution and interim suppression measures. | ||
| 398 | 5.4.2.5 Extended Detection and Response (XDR) Technical Requirements | ||
| 399 | 5.4.2.5.1 Data Ingestion and Normalization | ||
| 400 | 5.4.2.5.1.1 The solution shall support ingestion of telemetry from multiple security-relevant domains, enabling unified visibility, correlation, and advanced analytics across diverse environments. Supported telemetry sources shall include, but not be limited to: | ||
| 401 | 5.4.2.5.1.1.1 Endpoint | ||
| 402 | · Process, file, memory, and network activity | ||
| 403 | · Behavioural indicators and threat detections | ||
| 404 | · EDR and agent-generated events | ||
| 405 | 5.4.2.5.1.1.2 Firewall / IDS / NDR | ||
| 406 | · Network traffic metadata and flow records | ||
| 407 | · Intrusion detection/prevention alerts | ||
| 408 | · Protocol anomalies and lateral movement indicators | ||
| 409 | 5.4.2.5.1.1.3 DNS and Proxy | ||
| 410 | · DNS query and response logs | ||
| 411 | · Proxy access logs and URL filtering events | ||
| 412 | · Indicators of tunnelling, domain generation algorithms (DGA), and C2 activity | ||
| 413 | 5.4.2.5.1.1.4 Email Security | ||
| 414 | · Email delivery and filtering logs | ||
| 415 | · Phishing detection and sandbox results | ||
| 416 | · Attachment and link analysis metadata | ||
| 417 | 5.4.2.5.1.1.5 Identity and IAM | ||
| 418 | · Authentication and authorization events | ||
| 419 | · Privilege escalation and role changes | ||
| 420 | · Federation and SSO activity | ||
| 421 | · MFA status and anomalies | ||
| 422 | 5.4.2.5.1.1.6 CASB and SaaS | ||
| 423 | · Cloud application usage and access patterns | ||
| 424 | · Data movement and sharing events | ||
| 425 | · Policy violations and shadow IT detection | ||
| 426 | 5.4.2.5.1.1.7 Cloud Audit and Workload | ||
| 427 | · Cloud provider audit logs (e.g., AWS CloudTrail, Azure Activity Logs) | ||
| 428 | · VM/container activity and lifecycle events | ||
| 429 | · API calls, resource provisioning, and configuration changes | ||
| 430 | 5.4.2.5.1.1.8 OT and IoT (where applicable) | ||
| 431 | · Device telemetry and protocol-specific logs (e.g., Modbus, OPC-UA) | ||
| 432 | · Asset inventory and firmware status | ||
| 433 | · Behavioural anomalies and unauthorized access attempts | ||
| 434 | 5.4.2.5.1.2 The solution shall support push, pull, streaming (e.g., webhooks, Kafka), and batch ingestion methods. | ||
| 435 | 5.4.2.5.1.3 The XDR solution shall meet the following ingestion latency performance targets under normal operating conditions: | ||
| 436 | 5.4.2.5.1.3.1 Endpoint Telemetry | ||
| 437 | · Ingestion latency shall not exceed 15 seconds from data generation to availability in the XDR platform for analysis and correlation. | Armor cannot guarantee Microsoft platform SLOs | |
| 438 | · Applies to real-time endpoint events such as process creation, file access, and network connections. | Armor cannot guarantee Microsoft platform SLOs | |
| 439 | 5.4.2.5.1.3.2 Identity and Email Signals | ||
| 440 | · Ingestion latency shall not exceed 60 seconds from event occurrence to availability in the XDR platform. | Armor cannot guarantee Microsoft platform SLOs | |
| 441 | · Includes identity-related events (e.g., login attempts, MFA challenges) and email telemetry (e.g., phishing detection, message delivery status). | ||
| 442 | 5.4.2.5.1.3.3 Cloud Audit Logs | ||
| 443 | · Ingestion latency shall not exceed 120 seconds from log generation to ingestion into the XDR platform. | ||
| 444 | · Includes logs from cloud platforms (e.g., AWS CloudTrail, Azure Activity Logs, GCP Audit Logs). | ||
| 445 | 5.4.2.5.1.3.4 Measurement Criteria | ||
| 446 | · Latency shall be measured from the timestamp of the original event/log to the time it becomes queryable and usable for detection, alerting, or investigation within the XDR console or API. | Armor cannot guarantee Microsoft platform SLOs | |
| 447 | · Vendors shall provide documentation or benchmarks demonstrating compliance with these latency targets under typical workloads. | ||
| 448 | 5.4.2.5.1.3.5 Scalability and Load Conditions | ||
| 449 | · The solution shall maintain ingestion latency targets under scalable conditions, with the ability to handle increased data volumes without degradation in performance | While Microsoft Defender XDR is designed to handle large volumes of data, we cannot guarantee latency targets | |
| 450 | · Vendors shall describe how latency is affected by scale and provide tuning or architectural recommendations. | ||
| 451 | 5.4.2.5.1.3.6 Monitoring and SLA | ||
| 452 | · The solution shall include built-in telemetry or dashboards to monitor ingestion latency. | ||
| 453 | · Vendors shall commit to latency SLAs or provide mechanisms to alert when thresholds are breached. | Armor cannot guarantee Microsoft platform SLOs | |
| 454 | 5.4.2.5.1.4 The solution shall allow source-level filtering, sampling, and field suppression to reduce noise and control cost. | ||
| 455 | 5.4.2.5.1.5 The solution shall normalize all ingested data to a consistent and documented schema (e.g., OCSF-like mapping) with clear versioning. | ||
| 456 | 5.4.2.5.1.6 The solution must keep original event details and source information to support auditing. | ||
| 457 | 5.4.2.5.2 Context Enrichment & Asset Intelligence | ||
| 458 | 5.4.2.5.2.1 The solution shall perform entity resolution across users, accounts, devices, IP addresses, and SaaS identities, providing confidence scores for linkage. | ||
| 459 | 5.4.2.5.2.2 The solution shall maintain an asset inventory enriched with ownership, business criticality, and data classification attributes. | ||
| 460 | 5.4.2.5.2.3 The solution shall enrich telemetry with context such as reputation data, CMDB tags, vulnerability and exposure information, and business metadata. | ||
| 461 | 5.4.2.5.3 Detection and Analytics | ||
| 462 | 5.4.2.5.3.1 The solution shall provide a correlation engine capable of analysing temporal sequences, sliding windows, and threshold logic. | ||
| 463 | 5.4.2.5.3.2 The solution shall support machine-learning based correlation that identifies cross-domain attack patterns. | ||
| 464 | 5.4.2.5.3.3 The solution shall stitch together attack paths into unified incidents that combine signals from multiple domains. | ||
| 465 | 5.4.2.5.3.4 The solution shall calculate risk scores at both entity and incident levels to support triage prioritization. | ||
| 466 | 5.4.2.5.3.5 The solution shall automatically map incidents to MITRE ATT&CK and provide coverage dashboards with gap analysis. | ||
| 467 | 5.4.2.5.3.6 The solution shall include UEBA baselining of peer groups to detect behavioural anomalies. | ||
| 468 | 5.4.2.5.3.7 The solution shall detect and respond to a wide range of new or current adversarial tactics, techniques, and procedures (TTPs) as defined by the MITRE ATT&CK framework. Detection must include, but is not limited to: | ||
| 469 | 5.4.2.5.3.7.1 Identity and Access anomalies such as impossible travel, unusual OAuth grants, token theft, MFA fatigue, and Golden SAML indicators. | ||
| 470 | 5.4.2.5.3.7.2 Credential abuse including credential dumping, pass-the-hash, pass-the-ticket, NTLM downgrade attacks, and Kerberoasting. | ||
| 471 | 5.4.2.5.3.7.3 Kerberos-based threats such as Golden Ticket, Silver Ticket, and abnormal service ticket usage. | ||
| 472 | 5.4.2.5.3.7.4 Protocol abuse and relay attacks involving SMB relay, DCE/RPC misuse, WMI exploitation, and lateral movement via remote services. | ||
| 473 | 5.4.2.5.3.7.5 Fileless and Living-off-the-Land (LOTL) techniques using PowerShell, WMI, Rundll32, MSHTA, and signed binaries. | ||
| 474 | 5.4.2.5.3.7.6 Insider threat behaviours including off-hours access, privileged misuse, shadow IT usage, and attempts to disable security controls. | ||
| 475 | 5.4.2.5.3.7.7 Data staging and exfiltration such as anomalous data aggregation, compression/encryption prior to transfer, and cloud storage abuse. | ||
| 476 | 5.4.2.5.3.7.8 Email and communication threats including business email compromise (BEC), phishing, and social engineering. | ||
| 477 | 5.4.2.5.3.7.9 Command and Control (C2) behaviours such as beacon periodicity, domain generation algorithms (DGA), DNS tunnelling, and fallback channels. | ||
| 478 | 5.4.2.5.3.7.10 Persistence and privilege escalation via registry keys, process injection, service creation, and exploitation of vulnerabilities. | ||
| 479 | 5.4.2.5.3.7.11 Defence evasion techniques including obfuscation, disabling security tools, timestamping, and indicator removal. | ||
| 480 | 5.4.2.5.3.7.12 Discovery and reconnaissance such as account enumeration, network scanning, and Active Directory group discovery. | ||
| 481 | 5.4.2.5.3.7.13 Execution techniques including script interpreters, exploitation for client execution, and native API abuse. | ||
| 482 | 5.4.2.5.3.7.14 Impact techniques such as ransomware encryption, service disruption, and system recovery inhibition. | ||
| 483 | 5.4.2.5.3.7.15 Cloud-specific threats including abuse of cloud credentials, cloud account brute force, and unauthorized access to cloud storage. | ||
| 484 | 5.4.2.5.3.7.16 Supply chain and third-party abuse involving compromised dependencies, software supply chain manipulation, and third-party account misuse. | ||
| 485 | 5.4.2.5.3.7.17 Container and virtualization threats such as container escape, image modification, and host compromise. | ||
| 486 | 5.4.2.5.3.7.18 Mobile and IoT threats including credential dumping, malicious app delivery, and radio interface exploitation. | ||
| 487 | 5.4.2.5.3.7.19 Advanced evasion and anti-forensics such as file deletion, hidden users, and stealthy persistence mechanisms. | ||
| 488 | 5.4.2.5.3.7.20 AI/ML-based threats including prompt injection, model evasion, and abuse of AI-powered automation. | ||
| 489 | 5.4.2.5.3.7.21 Pre-attack indicators such as external reconnaissance, credential stuffing, and dark web mentions of internal assets. | ||
| 490 | Detection must leverage telemetry correlation, behavioural analytics, machine learning, and threat intelligence to identify known and unknown threats across endpoint, identity, network, cloud, and application layers. | ||
| 491 | 5.4.2.5.3.8 The solution shall incorporate Explainable AI (XAI) capabilities to ensure transparency and trust in automated threat detection. It shall: | ||
| 492 | · Surface feature importance, highlighting the key data attributes or behavioural signals that contributed most to a detection decision (e.g., login location, process behaviour, token or privilege anomalies, lateral-movement indicators). | ||
| 493 | · Provide decision rationale, including clear human-interpretable summaries of model outputs, scoring or confidence thresholds, behavioural correlations and the contributing telemetry sources used in the detection. | ||
| 494 | · Support analyst feedback loops, enabling security analysts to: | ||
| 495 | ü Confirm or reject detections. | ||
| 496 | ü Provide contextual input to improve model accuracy and relevance. | ||
| 497 | ü Tune the sensitivity or importance of specific detection rules, behaviours, or baselines to refine future detections. | ||
| 498 | · Maintain a feedback audit trail to track analyst interactions, model adjustments, behaviour-baseline changes, and the evolution of detection logic over time. | ||
| 499 | · Ensure that AI-driven detections are auditable, reproducible, and adjustable, providing consistent, transparent, and explainable outputs that meet operational, and compliance requirements. | ||
| 500 | 5.4.2.5.4 Incident Response and Orchestration | ||
| 501 | 5.4.2.5.4.1 The solution shall include a visual playbook editor with version control, test and simulation modes, error handling, and retry mechanisms. | ||
| 502 | 5.4.2.5.4.2 The solution shall orchestrate response actions across multiple domains, such as isolating endpoints, blocking firewall traffic, disabling IdP accounts, purging emails, revoking SaaS sessions, or rotating cloud keys. | ||
| 503 | 5.4.2.5.4.3 The XDR solution shall support automated and orchestrated response actions across multiple security domains, enabling rapid containment and mitigation of threats. The solution must be capable of executing the following actions: | ||
| 504 | 5.4.2.5.4.3.1 Endpoint Security | ||
| 505 | · Isolate compromised endpoints from the network | ||
| 506 | · Terminate malicious processes or sessions | ||
| 507 | · Trigger endpoint scans or remediation scripts | ||
| 508 | 5.4.2.5.4.3.2 Network and Firewall | ||
| 509 | · Block IP addresses, domains, or URLs at the firewall or proxy level | ||
| 510 | · Modify firewall rules or access control lists (ACLs) | ||
| 511 | · Quarantine affected network segments or VLANs | Custom Automation needed | |
| 512 | 5.4.2.5.4.3.3 Identity and Access Management (IdP) | ||
| 513 | · Disable or suspend user accounts in identity providers (e.g., Microsoft Entra ID, Okta) | ||
| 514 | · Revoke active sessions or tokens | ||
| 515 | · Enforce password resets or MFA challenges | ||
| 516 | 5.4.2.5.4.3.4 Multi-Factor Authentication | ||
| 517 | · Enforce step-up or adaptive MFA policies | ||
| 518 | · Block or restrict access based on risk signals | ||
| 519 | · Trigger MFA challenges or session terminations in real time | ||
| 520 | 5.4.2.5.4.3.5 Email and Collaboration (Microsoft 365) | ||
| 521 | · Purge malicious or suspicious emails from Exchange Online mailboxes | ||
| 522 | · Block sender domains or URLs in Microsoft Defender for Office 365 | ||
| 523 | · Quarantine or reclassify messages | ||
| 524 | · Disable or restrict access to SharePoint Online, OneDrive, or Teams resources | ||
| 525 | 5.4.2.5.4.3.6 Cloud and SaaS Platforms | ||
| 526 | · Revoke OAuth tokens or API keys | ||
| 527 | · Rotate compromised cloud access keys or credentials | ||
| 528 | · Disable or restrict access to affected cloud resources or SaaS apps (e.g., Microsoft 365, AWS, Google Workspace) | ||
| 529 | 5.4.2.5.4.3.7 Additional Requirements | ||
| 530 | · Response actions must be automated, manual, or hybrid, with full audit logging. | ||
| 531 | · The solution shall support role-based access control (RBAC) for response actions. | ||
| 532 | · Orchestration must be policy-driven and integrated with playbooks. | ||
| 533 | · Vendors shall provide a list of supported integrations and APIs, including Microsoft 365 security and compliance APIs. | ||
| 534 | 5.4.2.5.4.4 The solution shall enforce approval gates for high-impact steps and implement RACI models to define who can approve or execute actions. | ||
| 535 | 5.4.2.5.4.5 The solution shall integrate with ITSM systems to open, update, and close tickets, as well as with collaboration platforms for priority incidents. | ||
| 536 | 5.4.2.5.4.6 The solution shall provide prebuilt automated playbooks and detection logic for the following common threat scenarios, each with measurable time-to-detect and time-to-contain objectives. | ||
| 537 | 5.4.2.5.4.7 Playbooks must be customizable, support manual override, and integrate with external SOAR or ITSM platforms. | ||
| 538 | 5.4.2.5.4.8 Detection logic must be continuously updated by the vendor to reflect emerging threats. | ||
| 539 | 5.4.2.5.4.9 The solution shall provide audit logs, execution reports, and metrics dashboards for both detection and response workflows. | ||
| 540 | 5.4.2.5.4.10 Each scenario must include predefined detection rules, behavioural analytics, or machine learning models capable of identifying threats with high fidelity. | ||
| 541 | Detection logic must support: | ||
| 542 | · MITRE ATT&CK mapping | ||
| 543 | · False positive reduction mechanisms | ||
| 544 | · Custom rule creation and tuning | ||
| 545 | Time-to-detect shall be: | ||
| 546 | · ≤ 1 minute for endpoint-based threats | While Microsoft defender has near real time detections, there are no SLOs/SLAs that can be guaranteed for the product | |
| 547 | · ≤ 5 minutes for identity, email, or cloud-based threats | While Microsoft defender has near real time detections, there are no SLOs/SLAs that can be guaranteed for the product | |
| 548 | 5.4.2.5.4.11 Automated Playbooks and Containment Objectives | ||
| 550 | 5.4.2.5.4.12 The solution shall provide a unified, cloud-native Incident Lifecycle Management Framework that seamlessly integrates detection, triage, investigation, containment, eradication, recovery, and closure within a single operational platform. | ||
| 551 | 5.4.2.5.4.13 The framework shall be natively integrated with telemetry, analytics, and orchestration capabilities, enabling automated detection-to-response workflows, dynamic SLA management, and evidence-grade auditability. | ||
| 552 | 5.4.2.5.4.14 The Solution shall align with industry standards such as NIST SP 800-61 r2, MITRE ATT&CK, and SANS Incident-Handling methodologies, and must facilitate continuous SOC maturity improvement through automation, analytics, and machine-learning insights. | ||
| 553 | 5.4.2.5.4.14.1 Lifecycle Tracking | ||
| 554 | · The Solution shall maintain a single, persistent incident object across all lifecycle phases, automatically correlating alerts, detections, and analyst actions. | ||
| 555 | · Each incident shall display clear and configurable status indicators (Open, In Progress, Contained, Resolved, Closed), updated in real time. | ||
| 556 | · Automated workflow orchestration shall be supported, allowing incident transitions and task assignments to be triggered by detection rules, playbooks, or API integrations. | ||
| 557 | · The Platform shall provide role-based workspace for analysts, responders, and auditors, offering contextual views of the same incident without data duplication. | ||
| 558 | · Built-in secure collaboration (threaded comments, task tagging, attachments) shall ensure evidentiary continuity and reduce context-switching. | ||
| 559 | · The Solution shall support bi-directional synchronisation with enterprise ITSM platforms to maintain consistent case tracking and SLA alignment. | ||
| 560 | · The architecture shall enable cloud-scale multi-tenant management, allowing segmentation by business units, environment, or region while preserving central oversight. | ||
| 561 | 5.4.2.5.4.14.2 SLA Timers | ||
| 562 | · The Solution shall provide real-time SLA telemetry across each incident phase, including time-to-detect, time-to-acknowledge, time-to-contain, time-to-remediate, and time-to-close. | ||
| 563 | · SLA policies shall be fully configurable based on severity, asset classification, or detection source, and enforceable through automated escalation or reassignment. | ||
| 564 | · The system shall automatically notify relevant stakeholders of potential SLA breaches through integrated channels | ||
| 565 | · SLA performance data shall be continuously collected, visualized, and exportable, supporting metrics such as MTTD, MTTR, and containment efficiency. | ||
| 566 | · The Solution shall employ machine-learning-driven trend analysis to identify performance bottlenecks and recommend optimization of response workflows. | ||
| 567 | · SLA breaches and compliance records shall be retained as immutable audit data for governance and performance reporting. | ||
| 568 | 5.4.2.5.4.14.3 Evidentiary Bundles | ||
| 569 | · The Solution shall automatically generate evidentiary bundles for every incident, including: | ||
| 570 | ü Alert and detection metadata, correlated telemetry, and enriched threat intelligence. | ||
| 571 | ü Analyst actions, investigation steps, and timeline commentary. | ||
| 572 | ü Playbook execution logs and orchestration results. | ||
| 573 | ü Containment, remediation, and verification actions. | ||
| 574 | ü Chronological event timelines with timestamps. | ||
| 575 | · All evidentiary data shall be cryptographically timestamped and hash-verified to ensure forensic integrity. | ||
| 576 | · Bundles shall be retained in tamper-evident cloud storage with configurable retention and access control. | ||
| 577 | · Evidentiary packages shall be exportable in open and structured format (e.g., PDF, JSON, STIX 2.0) for legal, regulatory, or forensic use. | ||
| 578 | · The Solution shall support redaction, anonymization, and version control to enable secure sharing with third parties and compliance reviewers. | ||
| 579 | · The system shall support direct evidence replay from stored telemetry for re-analysis or validation. | ||
| 580 | 5.4.2.5.4.14.4 Reporting and Audit | ||
| 581 | · The Solution shall include dynamic dashboards and interactive reporting covering incident volume, classification, SLA adherence, and resolution metrics. | ||
| 582 | · The reporting engine shall support drill-down visualization to link incident outcomes to threat categories, affected assets, and contributing controls. | ||
| 583 | · The platform shall enable post-incident reviews and root-cause analysis (RCA) with built-in templates and automated data population. | ||
| 584 | · Reports shall be mapped to regulatory and governance frameworks (e.g., NIST CSF, ISO 27035) to demonstrate compliance readiness. | ||
| 585 | · Complete audit trails shall capture every user action, approval, data modification, and automation execution, retained per policy in immutable logs. | ||
| 586 | · The Solution shall leverage AI-driven analytics to surface recurring threat vectors, analyst workload trends, and opportunities for automated response optimization. | ||
| 587 | 5.4.2.4.4.13.5 Continuous Improvement and Automation | ||
| 588 | · The Solution shall incorporate a closed feedback loop between detection, response, and threat-hunting modules, enabling continuous enhancement of detection logic and response playbooks. | ||
| 589 | · Incident learning, playbook outcomes, and containment results shall automatically feed into detection-rule tuning and future automation decisions. | ||
| 590 | · The Solution shall expose open APIs and an automation framework for integrations with security, IT, and cloud ecosystems to orchestrate containment or remediation actions at scale. | ||
| 591 | · The platform shall provide automation efficacy metrics (e.g., percentage of incidents automatically contained or remediated, false-positive suppression rate). | ||
| 592 | · The Solution shall support low-code/no-code orchestration to allow authorized SOC engineers to create and modify playbooks without development effort. | ||
| 593 | 5.4.2.5.5 Dashboards, Reporting, and Compliance | ||
| 594 | 5.4.2.5.5.1 The solution shall provide role-based dashboards tailored for SOC analysts, leadership, and compliance officers, with configurable KPIs. | ||
| 595 | 5.4.2.5.5.2 The XDR solution shall provide visual dashboards and reporting capabilities to support operational visibility and performance tracking. Specifically, the solution must visualize: | ||
| 596 | 5.4.2.5.5.2.1 Incident and Threat Trends | ||
| 597 | · Volume and types of incidents over time | ||
| 598 | · Detection sources and affected domains | ||
| 599 | · Recurring threat patterns and campaign indicators | ||
| 600 | 5.4.2.5.5.2.2 Operational Metrics | ||
| 601 | · Mean Time to Detect (MTTD): Average time from threat occurrence to detection | ||
| 602 | · Mean Time to Respond (MTTR): Average time from detection to containment or remediation | ||
| 603 | · SLA compliance tracking for detection and response phases | ||
| 604 | 5.4.2.5.5.2.3 Risk-Based Insights | ||
| 605 | · Riskiest users based on behavioural anomalies, access patterns, and incident involvement | ||
| 606 | · Riskiest assets based on vulnerability exposure, threat activity, and criticality | ||
| 607 | · Risk scoring models must be transparent and customizable | ||
| 608 | 5.4.2.5.5.2.4 Detection Coverage | ||
| 609 | · Coverage across MITRE ATT&CK techniques and tactics | ||
| 610 | · Visibility into detection gaps by data source or telemetry type | ||
| 611 | · Mapping of detection rules to threat intelligence and known attack patterns | ||
| 612 | 5.4.2.5.5.3 The solution shall export reports in PDF, CSV, and JSON formats and provide a reporting API. | ||
| 613 | 5.4.2.5.5.4 The solution shall maintain immutable audit logs of all user and system actions with long-term retention. | ||
| 614 | 5.4.2.5.5.5 The solution shall offer PII minimization or pseudonymization in dashboards and reports, with workflows for authorized reveal. | ||
| 615 | 5.4.2.5.5.6 The solution shall provide compliance support by surfacing campaign clustering, Zero-Trust risk scoring, and audit-ready documentation. | ||
| 616 | 5.4.2.5.6 Scalability, Performance, and Availability | ||
| 617 | 5.4.2.5.6.1 The solution shall elastically scale to handle at least 200,000 events per second per tenant, with documented performance guidelines. | ||
| 618 | 5.4.2.5.6.2 The solution shall meet Service Level Objectives (SLOs) for ingestion latency, console availability, and action execution, and report on breaches of those SLOs. | Armor cannot guarantee Microsoft platform SLOs | |
| 619 | 5.4.2.5.6.3 The solution shall provide sandbox or test tenants with workflows for promoting content to production. | ||
| 620 | 5.4.2.5.6.4 The solution shall provide data flow documentation, and support for subsidiaries through cross-tenant federation while maintaining privacy boundaries. | ||
| 621 | 5.4.2.5.6.5 The solution shall support RWS-managed encryption keys and enforce key rotation policies, if applicable. | ||
| 622 | 5.4.2.5.6.6 The solution shall provide data tiering (hot, warm, cold) and policy-driven retention by source. | ||
| 623 | 5.4.2.5.6.7 The solution shall expose usage analytics for ingestion volumes, storage tiers, query costs, and top-talker sources. | ||
| 624 | 5.4.2.5.7 Threat Intelligence and Hunting | ||
| 625 | 5.4.2.5.7.1 The XDR solution shall support integration with external threat intelligence platforms and standards, enabling automated enrichment, correlation, and response. Specifically: | ||
| 626 | 5.4.2.5.7.1.1 Standards and Protocols | ||
| 627 | Must support ingestion and sharing of threat intelligence using: | ||
| 628 | · STIX 2.x (Structured Threat Information Expression) | ||
| 629 | · TAXII 2.x (Trusted Automated Exchange of Intelligence Information) | ||
| 630 | · MISP (Malware Information Sharing Platform) | ||
| 631 | · OpenCTI (Open Cyber Threat Intelligence Platform) via its GraphQL API or connector framework | ||
| 632 | 5.4.2.5.7.1.2 Functional Requirements | ||
| 633 | The solution shall: | ||
| 634 | · Parse and normalize threat indicators (IOCs) from STIX/TAXII, MISP, and OpenCTI feeds. | ||
| 635 | · Support scoring of threat indicators based on source reputation, confidence level, and contextual relevance. | ||
| 636 | · Perform deduplication of overlapping or repeated indicators across multiple feeds. | ||
| 637 | · Implement expiry management to automatically retire outdated or invalid indicators based on TTL, confidence decay, or source metadata. | ||
| 638 | 5.4.2.5.7.1.3 Operational Requirements | ||
| 639 | Threat intelligence must be usable in: | ||
| 640 | · Detection rules and correlation logic | ||
| 641 | · Automated playbooks and response workflows | ||
| 642 | · Dashboards and investigation views | ||
| 643 | 5.4.2.5.7.2 The solution shall re-evaluate historical data automatically against new intelligence within a defined window and open new cases where matches are found. | ||
| 644 | 5.4.2.5.7.3 The solution shall integrate sandbox detonation verdicts and correlate observed behaviours with endpoint, email, and identity events. | ||
| 645 | 5.4.2.5.7.4 The solution shall enrich incidents with adversary or actor intelligence, including known TTPs, infrastructure, and targets, along with confidence scoring. | ||
| 646 | 5.4.2.5.7.5 The solution shall provide hooks for attack simulation frameworks to validate detections and playbooks on demand in a non-production scope. | ||
| 647 | 5.4.2.5.7.6 The solution shall support retro-hunts based on new intelligence and deduplicate positive matches. | ||
| 648 | 5.4.2.5.7.7 The solution shall support YARA-based or IOC pack ingestion pipelines with deduplication, expiry, and tagging of matches to active cases. | ||
| 649 | 5.4.2.5.8 Integration and Extensibility | ||
| 650 | 5.4.2.5.8.1 The solution shall expose near-parity public APIs for all console functions, accompanied by SDKs and sample code. | Most console functions have public API | |
| 651 | 5.4.2.5.8.2 The solution shall provide connector SDKs and documentation for custom integrations. | ||
| 652 | 5.4.2.5.8.3 The solution shall integrate with downstream enforcement points and external knowledge bases through open formats such as JSON-LD. | ||
| 653 | 5.4.2.5.8.4 The solution shall integrate cloud provider logs (AWS, Azure Defender, GCP Audit/SCC), Kubernetes audit, and container runtime telemetry. | ||
| 654 | 5.4.2.5.8.5 The solution shall support ingestion of SaaS audit logs (e.g., M365/Graph) including OAuth scopes and consent events, and detect risks such as OAuth consent abuse, app-only tokens, suspicious mailbox rules, and unauthorized delegated access. | ||
| 655 | 5.4.2.5.9 Data Storage and Retention | ||
| 656 | 5.4.2.5.9.1 The Solution must support multi-tiered storage options – such as hot/active tier, warm/infrequent tier, cold/archive tier – to optimize performance and cost efficiency. | ||
| 658 | 5.4.2.5.10 Search and Query Capabilities | ||
| 659 | 5.4.2.5.10.1 The solution shall provide a pipeline or pipe-chaining query language with rich functions to filter, parse, transform, aggregate, join, and visualize data. | ||
| 660 | 5.4.2.5.10.2 The solution shall include function packs for common operations such as regex, conditional logic, and parsing helpers, with documented examples and best practices. | ||
| 661 | 5.4.2.5.10.3 The solution shall allow schema-on-read flattening for formats such as JSON, syslog, and CSV, while supporting field transforms including parse-json, URL decode, base64 decode, IP/CIDR operations, and type casting. | ||
| 662 | 5.4.2.5.10.4 The solution shall support index-free search so that new events are immediately searchable without requiring pre-indexing, enabling rapid scans of fresh data at scale. | ||
| 663 | 5.4.2.5.10.5 The XDR solution shall ensure that hot-tier search queries (i.e., searches over recently ingested and indexed data) meet the following latency performance targets: | ||
| 664 | 5.4.2.5.10.6 Search Latency Requirements | ||
| 665 | · Indexed lookups within the past 24 hours: Search results shall be returned in ≤ 3 seconds. | Armor cannot guarantee Microsoft platform SLOs | |
| 666 | · Searches over the past 7 days: Search results shall be returned in ≤ 7 seconds. | ||
| 667 | · Searches over the past 30 days: Search results shall be returned in ≤ 15 seconds. | ||
| 668 | 5.4.2.5.10.7 Latency shall be measured from the time the query is submitted to the time the first complete result set is returned to the user interface or API. | ||
| 669 | 5.4.2.5.10.8 The solution shall support: | ||
| 670 | · Index optimization for high-speed retrieval. | ||
| 671 | · Query parallelization or distributed search where applicable. | ||
| 672 | · Search performance monitoring and alerting for SLA breaches. | ||
| 673 | 5.4.2.5.10.9 The solution shall display performance metrics for each query to ensure transparency and provide concurrency controls to support at least fifty (50) simultaneous analyst queries with fair scheduling and priority for P1 investigations. | ||
| 674 | 5.4.2.5.10.10 The solution shall enable result caching and materialized views with configurable time-to-live (TTL) values for expansive queries and dashboards. | ||
| 675 | 5.4.2.5.10.11 The solution shall support live and streaming queries that update in real time and can be converted into historical windows or dashboards without requiring query rewrites. | ||
| 676 | 5.4.2.5.10.12 The solution shall provide a unified query surface across all domains including endpoint, identity, network, email, SaaS, and cloud audit data, with schema-on-read capabilities and a field or schema browser. | ||
| 677 | 5.4.2.5.10.13 The solution shall support graph and path queries across a unified entity graph linking users, devices, IPs, and applications, including sequence matching for multi-stage attack detection. | ||
| 678 | 5.4.2.5.11 Analyst Experience and Enrichment | ||
| 679 | 5.4.2.5.11.1 The solution shall provide autocomplete; inline documentation, examples, and grammar help within the query editor to reduce analyst time-to-query. | ||
| 680 | 5.4.2.5.11.2 The solution shall support joins and lookups across datasets and uploaded tables such as CSV or STIX, allowing ad-hoc enrichment without ETL (Extract, Transform, Load). | ||
| 681 | 5.4.2.5.11.3 The solution shall allow the ad-hoc upload of enrichment sets such as threat intelligence lists or asset tags, with TTL and RBAC, and expose lookup tables or key-value stores callable directly from queries. | ||
| 682 | 5.4.2.5.11.4 The solution shall provide a no-code query builder that generates valid DSL or SQL for less-experienced analysts while allowing export to the advanced editor. | ||
| 683 | 5.4.2.5.12 Threat Hunting and Detection | ||
| 684 | 5.4.2.5.12.1 The solution shall provide query packs and an interface for threat-hunting queries, including title, description, and keywords, along with search and tagging within a hunt library. | ||
| 685 | 5.4.2.5.12.2 The solution shall support retro-hunts and IoC sweeps that automatically re-evaluate recent history (e.g., 30–90 days) when new intelligence arrives and open cases when matches are found. | ||
| 686 | 5.4.2.5.12.3 The solution shall allow promotion of a query to a persistent detection rule with associated response actions such as kill, isolate, or notify, subject to approval gates. | ||
| 687 | 5.4.2.5.12.4 The solution shall provide attack storyline context as a queryable object, enabling hunts to pivot on process, script, file, or network chains rather than individual events. | ||
| 688 | 5.4.2.5.12.5 The solution shall maintain a curated query library mapped to MITRE ATT&CK, with versioning, ownership, peer reviews, and quality scores, and include sample content suitable for SIEM and SOAR workflows. | ||
| 689 | 5.4.2.5.13 Data Lake and Visualization | ||
| 690 | 5.4.2.5.13.1 The solution shall include a security data lake that normalizes telemetry from multiple sources into a common schema (e.g., OCSF) for search and analytics. | ||
| 691 | 5.4.2.5.13.2 The solution shall support dashboarding directly from queries, including tables, time-series, heatmaps, and graph views, with shareable RBAC-scoped links for collaboration. | ||
| 692 | 5.4.2.5.13.3 The solution shall provide dataset health signals such as freshness, lag, and drop rate, and optionally block queries on stale feeds to prevent misleading results. | ||
| 693 | 5.4.2.5.14 Governance, APIs, and Performance Guarantees | ||
| 694 | 5.4.2.5.14.1 The solution shall provide row- and field-level RBAC with PII masking and just-in-time reveal workflows that are fully audited. | ||
| 695 | 5.4.2.5.14.2 The solution shall expose query APIs through REST or SDKs, supporting both synchronous and asynchronous execution, pagination, streaming results, and export to formats such as CSV, JSON, Parquet, or object storage. | ||
| 696 | 5.4.2.5.14.3 The solution shall provide budget and cost guardrails, including maximum bytes, time, and concurrency limits, along with a kill-switch for runaway queries and per-user or per-team cost analytics. | ||
| 697 | 5.4.2.5.14.4 The solution shall support suppression of alerts derived from query results, allowing benign patterns to be excluded with expiration and review cycles to prevent long-term blind spots. | ||
| 698 | 5.4.2.5.14.5 The solution shall expose public API coverage for all search functions at near-parity with the UI and provide SDKs and example code. | Core search APIs exist (hunting, incidents). Full feature parity with the UI is not documented or guaranteed. | |
| 699 | 5.4.2.5.14.6 The solution shall deliver proof-of-concept acceptance by executing a mutually agreed search pack (including adversary sequences, UEBA anomalies, and threat intelligence matches), meeting defined latency and scale SLOs, and producing correct and reproducible results. | ||
| 700 | 5.4.2.6 Managed Extended Detection and Response Service (MXDR) | ||
| 701 | 5.4.2.6.1 Service Operations | ||
| 702 | 5.4.2.6.1.1 The service shall operate on a 24×7×365 basis, providing continuous monitoring, triage, investigation, and response. | ||
| 703 | 5.4.2.6.1.2 The service shall run fully within the RWS tenant using named accounts, MFA, and least-privilege roles, with no uncontrolled data export. | ||
| 704 | 5.4.2.6.1.3 The service shall use secure connectivity and auditable access methods such as privileged access management (PAM) or just-in-time (JIT) access, and enforce IP allow-listing. | ||
| 705 | 5.4.2.6.1.4 The service shall integrate MXDR workflows with RWS’s SIEM, XDR, and ITSM platforms for end-to-end case handling. | ||
| 706 | 5.4.2.6.1.5 The service shall define and agree escalation matrices (contacts, channels, working hours, languages) with RWS before go-live. | ||
| 707 | 5.4.2.6.1.6 The service shall continuously monitor the health of all data sources and generate alerts for gaps or stale feeds. | ||
| 708 | 5.4.2.6.1.7 The service shall require Singapore-based L2/L3 support engineers for escalation within 2 hours. | ||
| 709 | 5.4.2.6.2 Threat Intelligence & Triage | ||
| 710 | 5.4.2.6.2.1 The service shall perform intelligence-led triage using both commercial and community threat intelligence relevant to RWS’s industry. | ||
| 711 | 5.4.2.6.2.2 The service shall correlate context such as asset criticality, exposure, and business owner information during triage to ensure severity levels are set accurately. | ||
| 712 | 5.4.2.6.2.3 The service shall execute containment actions for pre-approved priority-one scenarios without waiting for RWS confirmation. | ||
| 713 | 5.4.2.6.2.4 The service shall conduct full investigations for confirmed threats and produce detailed root cause analyses. | ||
| 714 | 5.4.2.6.3 Threat Hunting and Detection Engineering | ||
| 715 | 5.4.2.6.3.1 The service shall perform scheduled threat hunts daily across all available telemetry. | ||
| 716 | 5.4.2.6.3.2 The service shall execute retro-hunts within 24 hours of receiving new indicators or actor TTPs. | ||
| 717 | 5.4.2.6.3.3 The service shall maintain a backlog for detection engineering, building and tuning rules with measurable precision and recall. | ||
| 718 | 5.4.2.6.3.4 The service shall maintain a coverage map and ATT&CK heatmap and regularly report detection gaps and remediation plans. | ||
| 719 | 5.4.2.6.3.5 The service shall manage and test response playbooks at least quarterly (including ransomware, business email compromise, insider threats, and cloud key theft) and report on time-to-contain. | ||
| 720 | 5.4.2.6.3.6 The service shall define hunt success KPIs, convert recurring hunts into detections, and provide actor-centric hunt packages aligned to current campaigns. | ||
| 721 | 5.4.2.6.3.7 The service shall operate a dedicated managed hunting function that searches daily for weak signals and campaign activity on priority assets, and daily across all data sources. | ||
| 722 | 5.4.2.6.3.8 The service shall publish time-to-hunt SLAs for new high-priority intelligence and show evidence of completion. | ||
| 723 | 5.4.2.6.4 Forensics, Investigations, and Containment | ||
| 724 | 5.4.2.6.4.1 The service shall provide remote forensic collection of host triage data, memory, and key artifacts with full chain-of-custody where permitted. | ||
| 725 | 5.4.2.6.4.2 The service shall provide remote containment and optional managed containment across endpoints, identity, email, and firewall, where pre-approved. | ||
| 726 | 5.4.2.6.4.3 The service shall coordinate change windows with RWS IT Security for high-impact response actions such as mass isolations and align those windows with RWS to avoid collateral impact. | ||
| 727 | 5.4.2.6.4.4 The service shall maintain immutable logs of all analyst actions, approvals, and rationale. | ||
| 728 | 5.4.2.6.4.5 The service shall maintain chain-of-custody discipline for all artifacts, including hash values, timestamps, and storage locations. | ||
| 729 | 5.4.2.6.5 Incident Management and Reporting | ||
| 730 | 5.4.2.6.5.1 The service shall deliver hourly updates on P1 incidents until containment is achieved, and daily updates until closure. | ||
| 731 | 5.4.2.6.5.2 The service shall provide daily critical summaries, weekly operational reports, and monthly KPI and SLA reports. | ||
| 732 | 5.4.2.6.5.3 The service shall deliver quarterly executive reviews covering threat trends, risks, and recommendations. | ||
| 733 | 5.4.2.6.5.4 The service shall track, and report mean time to detect (MTTD), mean time to respond (MTTR), and agreed action items from post-incident reviews. | ||
| 734 | 5.4.2.6.5.5 The service shall provide post-incident heightened monitoring and tuned anomaly thresholds to ensure that recurrence is prevented. | ||
| 735 | 5.4.2.6.5.6 The service shall provide debriefs and hardening guidance following every high-severity incident. | ||
| 736 | 5.4.2.6.6 Compliance, Audit, and Governance | ||
| 737 | 5.4.2.6.6.1 The service shall safeguard personally identifiable information (PII) and regulated data, adhering to RWS’s policies. | ||
| 738 | 5.4.2.6.6.2 The service shall provide compliance evidence packs on demand, including timelines, artifacts, and approvals. | ||
| 739 | 5.4.2.6.6.3 The service shall enforce data classification and retention requirements for artifacts and evidence, including secure deletion timelines. | ||
| 740 | 5.4.2.6.6.4 The service shall deliver standardized evidence packs suitable for audit and regulatory needs. | ||
| 741 | 5.4.2.6.6.5 All certification requirements applicable to the MXDR Provider shall be as specified under Functional Requirements, Section 9: Certification Requirements | ||
| 742 | 5.4.2.6.6.6 The service shall publish and maintain a threat intelligence curation policy covering sources, scoring, de-confliction, and false-intel handling, with defined refresh cadences. | ||
| 743 | 5.4.2.6.7 Collaboration and Engagement | ||
| 744 | 5.4.2.6.7.1 The service shall provide named escalation contacts and deputies for leadership communication. | ||
| 745 | 5.4.2.6.7.2 The service shall document a RACI matrix for all containment and remediation actions. | ||
| 746 | 5.4.2.6.7.3 The service shall support a co-managed model, allowing RWS analysts to participate in investigations. | ||
| 747 | 5.4.2.6.7.4 The service shall participate in tabletop exercises at least semi-annually. | ||
| 748 | 5.4.2.6.7.5 The service shall run quarterly workshops with RWS to support knowledge transfer and capability uplift. | ||
| 749 | 5.4.2.6.7.6 The service shall provide knowledge bases and runbooks with version control, ensuring content is always current. | ||
| 750 | 5.4.2.6.7.7 The service shall maintain sector-specific threat briefs, update watchlists and use cases accordingly, and provide visible change logs. | ||
| 751 | 5.4.2.6.8 Service Quality, Availability, and Improvement | ||
| 752 | 5.4.2.6.8.1 The service shall own the tuning process post go-live, targeting at least a 40% reduction in noise while preserving true positives. | ||
| 753 | 5.4.2.6.8.2 The service shall maintain service availability of 99.99% or higher for monitoring and case tooling. | ||
| 754 | 5.4.2.6.8.3 The service shall provide a service portal with live visibility into queues, SLAs, cases, and artifacts. | ||
| 755 | 5.4.2.6.8.4 The service shall provide surge capacity during outbreak events with defined ramp-up times, supported by surge routing to reprioritize analyst capacity automatically. | ||
| 756 | 5.4.2.6.8.5 The service shall demonstrate ongoing improvements through a documented development roadmap that includes assigned owners and target completion dates, along with the register of planned enhancements reviewed on a quarterly basis. | ||
| 757 | 5.4.2.6.8.6 The service shall deliver a signed onboarding runbook before go-live, covering connectivity, access, data sources, playbook inventory, and RACI. | ||
| 758 | 5.4.2.6.8.7 The service shall provide service transparency dashboards that display live SLAs, case volumes, actions taken, containment counts, and hunt KPIs. | ||
| 759 | 5.4.2.6.8.8 The service shall include continuous vulnerability intelligence review and contextual correlation across RWS-monitored assets to proactively identify exploitable weaknesses and provide actionable remediation guidance. | ||
| 760 | 5.4.2.6.8.9 The service shall collect and analyse vulnerability information from, but not limited to: | ||
| 761 | 5.4.2.6.8.9.1 Global repositories (CVE, NVD, CISA KEV, MITRE ATT&CK, vendor advisories). | ||
| 762 | 5.4.2.6.8.9.2 RWS-supplied scan results, asset inventories, and configuration baselines. | ||
| 763 | 5.4.2.6.8.9.3 Telemetry from XDR, EPP/EDR, network, identity, and cloud connectors and | ||
| 764 | 5.4.2.6.8.9.4 External or proprietary threat-intelligence feeds. | ||
| 765 | 5.4.2.6.8.10 The service shall include correlation of collected vulnerability data with RWS telemetry to determine actual exposure and exploitation likelihood. Each identified vulnerability shall be assigned a risk rating based on severity, exploitability, asset criticality, and business impact. A dynamic vulnerability-to-asset mapping shall be maintained and updated at least weekly. | ||
| 766 | 5.4.2.6.8.11 The service shall notify RWS of any critical or actively exploited vulnerability within twenty-four (24) hours of public disclosure or first observation. A Weekly Vulnerability Correlation Report shall be delivered every Monday of each week and shall include the following: | ||
| 767 | 5.4.2.6.8.11.1 Newly identified critical vulnerabilities (CVE ID, CVSS score and description) | ||
| 768 | 5.4.2.6.8.11.2 Confirmation whether the vulnerability has been observed or is potentially present in RWS telemetry. | ||
| 769 | 5.4.2.6.8.11.3 List of affected assets and corresponding risk ratings. | ||
| 770 | 5.4.2.6.8.11.4 Recommended mitigation or patch actions. | ||
| 771 | 5.4.2.6.8.11.5 Cross-reference to any related incidents or detections in the XDR platform. | ||
| 772 | 5.4.2.6.8.12 The service shall retain records of vulnerability sources, correlation logic, and notifications for a minimum of twelve (12) months. | ||
| 773 | 5.4.2.6.8.13 The service shall include continuous enhancement to its vulnerability correlation capabilities, including leveraging AI/ML models for prioritization and false-positive reduction. All AI-assisted outputs must remain explainable and auditable by RWS. | ||
| 774 | 5.4.2.6.9 Personnel and Expertise | ||
| 775 | 5.4.2.6.9.1 The service shall be physically located in Singapore, with all SOC operations handled exclusively by full-time, in-house personnel. Outsourcing of any SOC function shall be prohibited. | ||
| 776 | 5.4.2.6.9.2 The service shall perform background checks, security clearances, non-disclosure agreements, and annual ethics training for all in-house analysts. | ||
| 777 | 5.4.2.6.9.3 The service shall maintain skill matrices and certifications across disciplines including incident response, forensics, cloud security, and detection engineering. | ||
| 778 | 5.4.2.6.9.4 The service shall maintain a backup SOC in a separate geographic region to ensure operational continuity in case of local disruption. | ||
| 779 | 5.4.2.6.10 L1 Security Analyst | ||
| 780 | 5.4.2.6.10.1 The primary responsibility of the L1 Security Analyst is to handle day-to-day security incidents. | ||
| 781 | 5.4.2.6.10.2 Ensure all required or missing information related to a security incident is accurately filled in, including but not limited to hostname, user/owner of the host, domain, and physical/logical location of the host or user. | ||
| 782 | 5.4.2.6.10.3 Gather and attach relevance evidence to support the incident, such as logs, screenshots, or any other supporting documentation. | ||
| 783 | 5.4.2.6.10.4 Promptly escalate all security-related incidents (e.g., breaches, etc) to the SOC Manager. All email communications, including response and updates, shall be managed by the SOC Manager. | ||
| 784 | 5.4.2.6.10.5 Following the incident, the analyst must document a manual report detailing the workflow and methodology used. This report should serve as a reference for standardizing future response to similar incidents and must include all required fields, observations, and evidence. | ||
| 785 | 5.4.2.6.10.6 While monitoring dashboards, if any suspicious activity or anomaly is detected that requires further investigation, the analyst must create a manual incident report, populate all necessary fields, and escalate the case to Level 2 for further analysis. | ||
| 786 | 5.4.2.6.10.7 The analyst must possess a minimum of Blue Team Level 1 certification or an equivalent qualification (e.g., GCIA, CEH, ECSA, Security+, CPSA). | ||
| 787 | 5.4.2.6.11 L2 Security Analyst | ||
| 788 | 5.4.2.6.11.1 The Level 2 Analyst is responsible for reviewing and analysing incidents escalated by Level 1 Analysts, identifying correlations between the incident and the collected evidence. | ||
| 789 | 5.4.2.6.11.2 All relevant evidence, analyst notes, and references links must be attached to the corresponding security incident record. | ||
| 790 | 5.4.2.6.11.3 The analyst must assess and categorize the incident based on the following classifications: | ||
| 791 | 5.4.2.6.11.4 True Positive: An alert triggered correctly due to a legitimate threat, as defined by detection rules. | ||
| 792 | 5.4.2.6.11.5 True Negative: No alert triggered, and no threat present – systems behaving as expected. | ||
| 793 | 5.4.2.6.11.6 False Positive: An alert triggered without an actual threat, such as during approved penetration testing or benign activity. | ||
| 794 | 5.4.2.6.11.7 False Negative: A threat occurred, but no alert was triggered when it should have been. | ||
| 795 | 5.4.2.6.11.8 Based on the classification and severity of the incident, the Level 2 Analyst must determine whether escalation to the SOC Manager is warranted, | ||
| 796 | 5.4.2.6.11.9 The analyst must hold a minimum of Blue Team Level 2 certification or an equivalent qualification (e.g., GCIH) | ||
| 797 | 5.4.2.6.12 L3 (Technical Lead) | ||
| 798 | 5.4.2.6.12.1 Conducts in-depth reviews of asset discovery and vulnerability assessment data to identify potential security gaps and areas for improvement. | ||
| 799 | 5.4.2.6.12.2 Leads proactive threat hunting activities by leveraging the latest threat intelligence, tactics, techniques and procedures (TTPs) to uncover stealthy or advanced threats within RWS networks. Finding must be documented in a detailed report with recommendations for remediation. | ||
| 800 | 5.4.2.6.12.3 Performs controlled activities on production systems to validate system resiliency and uncover weaknesses that require remediation. | ||
| 801 | 5.4.2.6.12.4 Provides expert recommendations to optimize and fine-tune security monitoring tools and detection ules based on insights gained from threat hunting and incident analysis. | ||
| 802 | 5.4.2.6.12.5 Must possess a minimum of Blue Team Level 3 certification or an equivalent qualification (e.g., GCFA, GCFE) | ||
| 803 | 5.4.2.6.13 Technical Success Manager | ||
| 804 | 5.4.2.6.13.1 Act as the primary technical liaison for clients utilizing the managed security and platform services. Gain a deep understanding of client goals and business strategies to ensure service delivery aligns effectively. | ||
| 805 | 5.4.2.6.13.2 Manage the implementation and integration of security and platform solutions within client environments, ensuring configuration and customization follow industry best practices. | ||
| 806 | 5.4.2.6.13.3 Continuously assess service performance against client expectations and SLAs. Proactively identify and resolve issues to enhance service quality. | ||
| 807 | 5.4.2.6.13.4 Deliver comprehensive reports and updates to clients covering service status, compliance posture, security incidents, and performance indicators. | ||
| 808 | 5.4.2.6.13.5 Lead technical resolution efforts for service-related issues. Collaborate with internal teams to ensure swift problem-solving and minimal impact on client operations. | ||
| 809 | 5.4.2.6.13.6 Suggest improvements to security and platform services based on client input and emerging technologies. Contribute to product development initiatives to represent client interests. | ||
| 810 | 5.4.2.6.13.7 Provide training and expert guidance to clients on new functionalities and best practices for managing security and platform services. | ||
| 811 | 5.4.2.6.13.8 Ensure all service implementations adhere to applicable legal, regulatory, and security standards. Support clients in understanding and complying with these requirements. | ||
| 812 | 5.4.2.6.14 Advanced Capabilities | ||
| 813 | 5.4.2.6.14.1 The service shall provide vulnerability and asset context ingestion (e.g., from VM tools or asset criticality data) to improve triage without taking ownership of patching. | ||
| 814 | 5.4.2.6.14.2 The service shall provide malware analysis support, including rapid triage, static and dynamic analysis, and IOC extraction, with defined turnaround targets feeding into detections and playbooks. | ||
| 815 | 5.4.2.6.14.3 The service shall provide dark web monitoring in addition to surface web monitoring for at least 50 keywords or phrases, including but not limited to RWS domains and key third-party vendors. | ||
| 816 | 5.4.2.6.14.4 The service shall conduct continuous monitoring of the dark web for potential threats and exposures related to RWS and promptly address identified risks. | ||
| 817 | 5.4.2.6.14.5 The service shall support the onboarding of RWS-subscribed threat intelligence feeds into its operational workflows. | ||
| 818 | 5.5 Item 1: Provision of Endpoint Protection Platform (EPP), Endpoint Detection & Response (EDR), and Extended Detection & Response (XDR), including Migration from Existing Platform. | ||
| 819 | 5.5.1 The Supplier shall design, implement, and configure an integrated EPP/EDR/XDR solution platform in accordance with industry best practices, applicable legal and regulatory standards, and RWS’s internal requirements. | ||
| 820 | 5.5.2 The proposed design must incorporate resiliencies for all tiers (agents/sensors, control plane, ingestion/correlation, case store), including high availability, validated backup/restore, and automated failover/failback to prevent loss of prevention policies, telemetry, detection events, investigations, or incident data. | ||
| 821 | 5.5.3 The platform shall enforce role-based security for protected data and actions, including but not limited to: | ||
| 822 | 5.5.3.1 Role-based access controls (RBAC) and segregation of duties for deployment, policy/detector authoring, exception approvals, live response, and playbook execution. | ||
| 823 | 5.5.3.2 Full auditability of administrative, investigative, and response actions with immutable logs and retention aligned to policy. | ||
| 824 | 5.5.3.3 Assurances of data integrity for configurations, indicators, content/engines, telemetry, and evidence (e.g., signing, checksums, provenance and chain-of-custody). | ||
| 825 | 5.5.4 The solution shall integrate with the RWS’s enterprise systems, including but not limited to: | ||
| 826 | 5.5.4.1 Authentication and authorization (SSO, MFA, JIT, IP allow-listing). | ||
| 827 | 5.5.4.2 Communication, alerting, and collaboration tools (e.g., Microsoft Teams, Microsoft Outlook or equivalents) for notifications. | ||
| 828 | 5.5.4.3 IT Service Management (ITSM) platforms for ticket creation, approvals (e.g., quarantine restore), state synchronization, and SLA tracking. | ||
| 829 | 5.5.4.4 SIEM/CLM and/or data lake services for downstream analytics, compliance archiving, and reporting where applicable. | ||
| 830 | 5.5.5 The platform shall segregate data, policies, dashboards, and administration between Production and Non-Production environments, across different application systems, and by data classification, ensuring distinct handling and visibility where required. | ||
| 831 | 5.5.6 The solution shall be integrated with or include a native Security Orchestration, Automation and Response (SOAR) capability to support automated, auditable response workflows for EPP/EDR/XDR actions with approval gates and rollback. | ||
| 832 | 5.5.7 The platform shall automatically route, replicate, or divert prevention, telemetry, and incident data to designated destinations (e.g., SIEM/XDR, object storage, data lake) using secure transport with retry, and delivery confirmation. | ||
| 833 | 5.5.8 The solution shall prioritize security-relevant events for monitoring and detection including, at minimum, malware/exploit/ASR blocks, tamper attempts, quarantine and restore actions, credential theft indicators, persistence creation, lateral movement, identity anomalies, and anomalous egress. | ||
| 834 | 5.5.9 The Supplier shall provide a comprehensive onboarding document and categorized playbooks by domain and source type, covering endpoint (Windows, macOS, Linux, VDI persistent/non-persistent; servers), identity/IdP and PAM/IGA, email gateways, DNS/proxy, firewalls/NDR, cloud audit (AWS/Azure/GCP and other approved clouds), SaaS suites (e.g., Microsoft 365, CASB, CNAPP), vulnerability/context feeds, custom applications, and IoT/OT telemetry where available. | ||
| 835 | 5.5.10 Onboarding documentation must include detailed configuration procedures, schema/field mappings, validation steps, troubleshooting guidelines, and rollback instructions for agents/sensors, connectors, detections/playbooks, and dashboards. | ||
| 836 | 5.5.11 The Supplier shall implement intelligent tiered storage across EPP/EDR/XDR datasets (hot/warm/cold) to optimize cost and performance while complying with the retention requirements defined in Section 5.4.2.4 | ||
| 837 | 5.5.12 The Supplier shall assess, plan, and execute the migration of endpoints from the existing endpoint security tools to the new EPP/EDR platform, accommodating agent-based and coexistence configurations during transition and ensuring policy parity and safe rollback. | ||
| 838 | 5.5.13 The Supplier shall assess, plan, and execute the migration of connectors and data sources to the new XDR platform for agentless/API-based integrations (identity/IdP, email, DNS/proxy, firewalls/NDR, cloud audit, SaaS, vulnerability/context). | ||
| 839 | 5.5.14 The Supplier shall onboard all existing and newly identified sources into the platform. Source categories include, but are not limited to: | ||
| 840 | 5.5.14.1 Endpoint/EPP/EDR telemetry for client and server OS, including VDI. | ||
| 841 | 5.5.14.2 Identity and access systems (e.g., Azure AD/IdP), PAM and IGA. | ||
| 842 | 5.5.14.3 Security controls (e.g., antimalware, EDR, XDR, NDR, DLP, IDS/IPS, vulnerability management). | ||
| 843 | 5.5.14.4 Network devices (firewalls, routers, switches), DNS and secure web gateways. | ||
| 844 | 5.5.14.5 Cloud platforms (AWS, Azure, GCP and any RWS-approved clouds) and container/orchestrator audit logs. | ||
| 845 | 5.5.14.6 SaaS suites and security services (e.g., Microsoft 365, CASB, CNAPP), applications/middleware, and database activity telemetry. | ||
| 846 | 5.5.14.7 Custom-built applications and IoT/OT telemetry sources, where feasible. | ||
| 847 | 5.5.15 Where agent/sensor deployment is required, the Supplier shall plan, install, configure, test, validate, load/performance-test, and operationally hand over packaging and deployment (MSI/MSIX/PKG/DEB/RPM; signing/notarization; Intune/SCCM/GPO). | ||
| 848 | 5.5.16 The Supplier must ensure that migration, agent/sensor installation, connector cutover, and data forwarding occur without disruption to business applications or operations; performance guardrails (CPU/RAM/battery/network awareness) and server-safe response guardrails (e.g., never isolate domain controllers without approval) shall be enforced. | ||
| 849 | 5.5.17 The Supplier shall review and migrate EPP configurations; where incompatible, the Supplier shall implement functionally equivalent controls aligned to best practices and RWS requirements, subject to RWS validation. Examples include policy sets, attack-surface reduction, device/app control, exclusions, update rings, user notification policies, dashboards, and reports. | ||
| 850 | 5.5.18 The Supplier shall review and migrate EDR configurations, implementing equivalent logic where direct translation is not feasible. Examples include telemetry scope and collection policies, suppression/allow lists, scheduled hunts, live-response prerequisites, dashboards/reports, case templates, and chain-of-custody settings. | ||
| 851 | 5.5.19 The Supplier must review existing EPP/EDR/XDR configurations and migrate them as needed, ensuring equivalent functionality. This includes items such as schema mappings, entity resolution, correlation rules, machine learning models, thresholds, detection logic, schedules, filters, UEBA settings, dashboards, reports, and SOAR playbooks | ||
| 852 | 5.5.20 All migrated configurations shall be validated by RWS to ensure functional equivalence and operational effectiveness, with evidence captured in acceptance artifacts. | ||
| 853 | 5.5.21 The solution must offer EDR investigation and response features, including process tree and timeline views, pivoting across host, user, hash, domain, and IP, secure live response (e.g., remote shell, file and memory triage) with role-based access control and approvals, and response actions such as network isolation, process termination, file quarantine or restore, and hash blocking—all with immutable audit logs | ||
| 854 | 5.5.22 The solution shall provide an expressive hunting and query capability (regex, joins/subqueries, time windows and sequence operators, schema browser/autocomplete), with saved and scheduled hunts, curated hunt libraries, and automatic retro-hunts when new intelligence arrives. | ||
| 855 | 5.5.23 The solution must support ransomware recovery where supported by the operating system, including rollback and restore using snapshots, with success tracking and reporting. | ||
| 856 | 5.5.24 The XDR layer shall provide ingestion Service Level Objectives (SLOs) and monitoring dashboards: median ingestion for endpoint < 15 seconds, identity/email < 60 seconds, and cloud audit < 120 seconds (under agreed volumes), with health alerts on connector lag, drop rate, or schema errors. | We do not guarantee platform SLOs | |
| 857 | 5.5.25 The EDR layer shall achieve new event searchability ≤ 60 seconds median and isolation command ≤ 30 seconds for online endpoints (under agreed conditions) with published latency dashboards. | We do not guarantee platform SLOs | |
| 858 | 5.5.26 The XDR layer shall include UEBA to baseline peer/seasonal behavior and detect anomalies (e.g., impossible travel, rare parent-child pairs, unusual OAuth grants, anomalous egress) and shall compute risk scores at entity and incident levels for routing and prioritization. | ||
| 859 | 5.5.27 The platform shall normalize all ingested data to a documented schema with versioning, preserve raw source fields, deduplicate events while recording provenance, and enrich with CMDB ownership, asset criticality, and vulnerability/context data. | ||
| 860 | 5.5.28 The platform shall support correlation of temporal sequences across domains and stitch multi-signal incidents mapped to MITRE ATT&CK, with campaign clustering, incident lifecycle management, SLA timers, and evidentiary bundles. | ||
| 861 | 5.5.29 The platform shall provide a visual playbook editor with versioning, test/simulation mode, retries/error handling, approval gates, rollback, and orchestration of cross-domain actions (endpoint isolation, firewall block, IdP disable, email purge, SaaS session revoke, cloud key rotation). | ||
| 862 | 5.5.30 The solution shall expose REST APIs/SDKs for search/queries, incidents/cases, response actions, and export of results (CSV/JSON/Parquet) to object storage, and shall integrate with collaboration and ITSM systems for ticket lifecycle. | ||
| 863 | 5.5.31 The solution shall implement budget/volume guardrails (quotas, throttles, priority queues) with alerts and kill-switches to prevent runaway workloads while preserving priority sources and P1 response. | ||
| 864 | 5.5.32 The platform shall provide dashboards and reports generated directly from queries, including ingestion latency by source, searchable-data latency, incident stitching accuracy, ATT&CK coverage, MTTD/MTTR, playbook time-to-contain, UEBA alert quality, and ingest/cost by source. | ||
| 865 | 5.5.33 The Supplier shall deliver all documentation, scripts, templates, and training materials, and conduct role-based training and workshops (administrators, SOC analysts, service desk) covering operations, investigations, hunts, playbook authoring, and change governance. | ||
| 866 | 5.5.34 The Supplier shall provide Go-Live support to meet all RWS requirements, including completion of required artifacts, issue-log tracking, acceptance and integration testing, security hardening and vulnerability remediation, governance approvals, security validations, knowledge transfer, final documentation, and operational readiness sign-off. | ||
| 867 | 5.5.35 The Supplier must ensure all activities above comply with the RWS’s security and privacy requirements, including encryption in transit and at rest, optional RWS-managed keys, field-level masking and just-in-time reveal with audit, and immutable logging of all administrative and response actions. | ||
| 868 | 5.5.36 The Supplier shall execute all migrations and cutovers with no disruption to business operations, shall maintain performance guardrails for endpoints and servers, and shall provide rollback plans approved by the RWS’s change governance. | ||
| 869 | 5.6 The supplier shall ensure the following critical milestones and timeline are met. | ||
| 870 | System Commissioning: On or before 1st June 2026 | ||
| 871 | MXDR Services Start: Immediately once any asset is onboarded | ||
| 872 | Full Onboarding & Operational: By 31st December 2026 | ||
| 873 | 5.7 Item 2: Managed Extended Detection and Response (MXDR) to provide security monitoring services, operate and maintain the solution platform. | ||
| 874 | 5.7.1 The Supplier shall provide continuous 24×7×365 monitoring and maintenance of RWS’s EPP, EDR, and XDR platforms. The Managed Extended Detection and Response Service (MXDR) must ensure optimal operational performance, reliable platform and connector functionality, and swift incident response through proactive threat prevention, detection, analysis, and coordinated mitigation across endpoints and cross-domain telemetry. Core capabilities must include: | ||
| 875 | 5.7.1.1 Continuous monitoring and analysis of EPP prevention events (malware/exploit/ASR blocks, tamper attempts, quarantine/restore, device & application control violations), EDR detections/telemetry (process/file/registry/plist, network/DNS, authentication, script/AMSI, memory/injection where available), and XDR multi-source incidents. | ||
| 876 | 5.7.1.2 Establishment of baseline profiles for routine endpoint, user, device, application, and connector activity (Production and Non-Production) to support anomaly detection, including spikes in prevention events, policy drift, rare parent-child process pairs, impossible travel, unusual OAuth grants, and anomalous egress. | ||
| 877 | 5.7.1.3 Correlation of multiple events across hosts, users, identities, network, cloud, SaaS, and email telemetry with entity resolution to reconstruct attack storylines/kill chains and distinguish false positives from true threats. | ||
| 878 | 5.7.1.4 Application of user and entity behaviour analytics (UEBA) and behaviour heuristics to enhance detection of credential abuse, insider risk, persistence, and lateral movement while reducing false positives. | ||
| 879 | 5.7.1.5 Monitoring of privileged activities and admin tool usage across domains (e.g., endpoint tamper, LSASS access attempts, service creation, role/privilege changes, key rotations, mailbox rule creation) to identify suspicious or anomalous behaviour. | ||
| 880 | 5.7.1.6 Cyber surveillance and incident response capabilities, including endpoint isolation, process termination, file quarantine/restore, hash blocklists, identity disablement, firewall blocks, email purge, SaaS session revocation, and cloud key rotation, executed via governed SOAR playbooks with approvals and rollback. | ||
| 881 | 5.7.1.7 Threat detection enrichment through integration of cyber threat intelligence (IOC/STIX/TAXII) with TTL, scoring, de-duplication, and retro-evaluation/retro-hunts of recent history upon receipt of new indicators. | ||
| 882 | 5.7.1.8 Timely escalation, response, and reporting of security incidents per SLA, including P1 activation, leadership updates, and evidentiary timelines with chain-of-custody. | ||
| 883 | 5.7.1.9 Recommendation of action plans to mitigate reported threats (policy hardening, tuned suppressions with expiry/review, playbook improvements, response guardrails), with measurable follow-ups and closure evidence. | ||
| 884 | 5.7.2 The MXDR provider must demonstrate a clear understanding of, and strict adherence to, industry-recognized standards, regulatory requirements, and compliance frameworks relevant to RWS’s operational environment and threat landscape. | ||
| 885 | 5.7.3 The MXDR Provider’s certification obligations shall follow the Certification Requirements under Functional Requirements, Section 9, which governs all Day1, Day2 and platform-level certification requirements. | ||
| 886 | 5.7.4 The MXDR provider shall offer multiple communication channels for incident notifications and discussions (telephone, email, and portal/ticketing) to ensure RWS can promptly reach SOC personnel within three attempts or fifteen (15) minutes, whichever is sooner. | ||
| 887 | 5.7.5 The MXDR provider must maintain a robust Business Continuity and Disaster Recovery (BC/DR) program for SOC operations and for XDR connectors/ingest pipelines, ensuring uninterrupted service delivery during disruptions or outages. | ||
| 888 | 5.7.6 The MXDR provider shall deliver a case management system that supports the creation, updating, and closure of incident tickets and integrates with RWS’s EPP/EDR/XDR and ITSM to enable automatic ticket generation and status synchronization based on detections, playbook outcomes, and governed approvals. | ||
| 889 | 5.7.7 The MXDR provider shall assign a single point of contact to coordinate and manage onboarding, content promotion, connector health governance, and steady-state operations. | ||
| 890 | 5.7.8 The MXDR provider must have an in-house team dedicated to EPP policy management, EDR detection engineering and hunting, and XDR correlation/UEBA/playbook development, without reliance on external vendors; all content and policy changes are subject to RWS approval prior to production. | ||
| 891 | 5.7.9 The MXDR provider shall be responsible for continuous fine-tuning of EPP policies/exclusions and device/app control, EDR rules/hunts/suppressions, and XDR detections, UEBA thresholds, correlation rules, and SOAR playbooks throughout the contract, with precision/recall and noise-reduction metrics tracked. | ||
| 892 | 5.7.10 The MXDR provider shall deploy all applicable content from vendor libraries (prevention policies, detections, hunts, queries, correlation rules, UEBA models, and playbooks) based on the onboarded sources and endpoint/server types, without limitation on the number implemented. | ||
| 893 | 5.7.11 The MXDR provider must ensure rapid response for critical EPP/EDR/XDR events. Notifications shall be issued as per SLA upon initial alerts from pre-defined use cases, accompanied by actionable guidance and recommended remediation steps, including containment decisions and business impact summaries. | ||
| 894 | 5.8 Item 3: Platform Maintenance and Management (Platform Maintenance, Log/Sensor & Connector Onboarding and Management, Use Case/Content Development and Tuning, Dashboard and Reporting Customization, Data Retention and Archiving Management) | ||
| 895 | 5.8.1 The MXDR shall provide continuous monitoring of the System or Solution platform’s health, performance, and availability across EPP, EDR, and XDR and the MXDR service. This includes, but is not limited to, monitoring endpoint agent/sensor status and version compliance, connector/service status, resource utilization (CPU, memory, storage), endpoint coverage, log and telemetry ingestion rates, backlog/lag, and pipeline/service status to ensure uninterrupted and efficient operations. | ||
| 896 | 5.8.2 The MXDR shall ensure timely implementation of security patches, hotfixes, and major version upgrades for the System or Solution platform and all associated components (e.g., EPP/EDR agents and content, XDR connectors, SOAR apps/integrations, operating systems, parsers) including remediation of any known vulnerabilities. All updates shall follow RWS’s change management processes with pre-checks and rollback plans, ensuring that no component (including endpoint agents/sensors, playbooks, or connectors) remains operational beyond its End of Support Life (EOSL). | ||
| 897 | 5.8.3 The MXDR shall conduct continuous reviews and enhancements of System or Solution configurations spanning EPP policies, EDR detections/hunts, and XDR correlation/UEBA/playbooks. Activities include, but are not limited to, onboarding of log sources and endpoint sensors, development/refinement of parsing and normalization rules, correlation and detection logic, UEBA thresholds, dashboard customization, log/telemetry storage management, rule and offence tuning, system and agent patching, and SOAR workflow refinements. These activities shall maintain optimal performance, accuracy, and relevance of the System or Solution platform. | ||
| 898 | 5.8.4 The MXDR shall continuously optimize the System or Solution platform to ensure efficient data collection (agents/sensors/connectors), processing, storage, and retrieval. Optimization shall adapt to changes in endpoint count, telemetry/log volume, use-case load, and evolving organizational requirements, ensuring scalability and sustained performance (including hot/warm/cold tiering, index-free/search tier parameters where applicable, and cost guardrails). | ||
| 899 | 5.8.5 The MXDR shall continuously develop, refine, and tune use cases and content across EPP/EDR/XDR to detect emerging threats and minimize false positives. This includes prevention policy tuning (EPP), behaviour detections and hunts (EDR), correlation rules and UEBA models (XDR), de-duplication/suppression hygiene, and SOAR playbook enhancements. | ||
| 900 | 5.8.6 The MXDR shall customize and develop dashboards, reports, and alerting mechanisms to meet RWS’s operational and reporting requirements for endpoint coverage/health, detection/response KPIs (e.g., MTTD/MTTR, time-to-isolate, playbook time-to-contain), ingestion/connector health, ATT&CK coverage heatmaps, and executive summaries, ensuring relevance and usability for SOC, IT operations, compliance, and leadership stakeholders. | ||
| 901 | 5.8.7 The MXDR shall manage data retention policies and archiving strategies across EPP prevention logs, EDR telemetry and case artifacts, and XDR normalized/correlated data, in strict accordance with RWS’s internal requirements and applicable regulatory obligations. Management shall include integrity checks, legal hold, immutable evidence retention for incidents, and verifiable purge on expiry. | ||
| 902 | 5.8.8 The MXDR shall deliver regular, in-depth reporting that covers security incidents, threat intelligence updates, platform performance and optimization efforts, backlog and data ingestion health, tuning results (including precision, recall, and noise reduction), and overall service delivery metrics. A well-defined communication and escalation framework must be maintained to ensure prompt and effective responses to incidents and service disruptions, including clear thresholds for P1/P2 events and leadership notification protocols. | ||
| 903 | 5.8.9 Security Operations Centre (SOC) Operations – Continuous Threat Monitoring | ||
| 904 | 5.8.9.1 The MXDR shall conduct proactive and continuous monitoring of security events and alerts generated by the System or Solution platform and other integrated security technologies, including EPP prevention events, EDR detections and telemetry, and XDR cross-domain incidents, to identify potential threats in real-time. | ||
| 905 | 5.8.10 Incident Detection, Response, Triage and Analysis | ||
| 906 | 5.8.10.1 The MXDR shall perform efficient triage, validation, and detailed analysis of security alerts to distinguish genuine threats from false positives. Responsibilities include: | ||
| 907 | 5.8.10.1.1 Timely detection of security incidents such as malware/exploit activity, tamper events, credential abuse, persistence and lateral movement, unauthorized access attempts, data exfiltration, cloud/SaaS misuse, and anomalous network activity observed via EPP/EDR/XDR. | ||
| 908 | 5.8.10.1.2 Immediate notification to RWS’s designated contacts based on predefined severity levels and escalation protocols, with activation of collaboration channels. | ||
| 909 | 5.8.10.1.3 Execution of predefined incident response playbooks orchestrating endpoint isolation, process termination, file quarantine/restore, identity disablement, firewall blocks, email purge, SaaS session revocation, and cloud key rotation with approvals and rollback. | ||
| 910 | 5.8.10.1.4 Coordination of forensic support and live response where permitted (remote shell, file/memory triage), ensuring chain-of-custody for all collected artifacts and preservation of evidence for potential legal/regulatory matters. | ||
| 911 | 5.8.10.1.5 Participation in post-incident reviews to identify root causes, document lessons learned, and recommend corrective and preventive actions, tracking of actions to closure. | ||
| 912 | 5.8.10.1.6 Delivery of comprehensive incident report per case, including timeline, indicators, affected asset/users, containment/remediation actions, residual risk, and business impact summary. | ||
| 913 | 5.8.11 Threat Intelligence and Threat Hunting | ||
| 914 | 5.8.11.1 The MXDR shall integrate and utilize reputable threat intelligence feeds at no cost to RWS, within the System or Solution platform to enhance detection capabilities and situational awareness, with indicator TTL, scoring, and de-duplication. | ||
| 915 | 5.8.11.2 The MXDR shall conduct proactive and iterative threat hunting across RWS’s environment using EDR telemetry and XDR multi-source data to uncover hidden threats, APT activity, and sophisticated attack vectors that may bypass automated detection, and shall promote validated hunts into persistent detections/rules. | ||
| 916 | 5.8.11.3 The MXDR shall provide actionable intelligence on emerging campaigns, vulnerabilities, and threat actor tactics relevant to RWS’s landscape, including Indicators of Compromise (IOCs), technique notes, and strategic advisories with prioritized mitigation steps mapped to ATT&CK. | ||
| 917 | 5.8.11.4 The threat intelligence provided must be tailored to RWS’s diverse business sectors, including but not limited to | ||
| 918 | 5.8.11.4.1 Gaming (Casino) | ||
| 919 | 5.8.11.4.2 Attractions | ||
| 920 | 5.8.11.4.3 Hotels | ||
| 921 | 5.8.11.4.4 Food & Beverage | ||
| 922 | 5.8.11.4.5 Meeting, Incentives, Conferences and Exhibitions (MICE) | ||
| 923 | 5.8.11.4.6 Tourism and Hospitality | ||
| 924 | 5.8.11.4.7 Retail | ||
| 925 | 5.8.12 Security Orchestration, Automation, and Response (SOAR) | ||
| 926 | 5.8.12.1 The MXDR shall design, implement, and maintain automation playbooks within the SIEM/SOAR/XDR environment to streamline repetitive tasks, accelerate incident response, and enhance operational efficiency; playbooks shall include error handling, retries, approvals, and rollback. | ||
| 927 | 5.8.12.2 The MXDR shall ensure seamless integration of the System or Solution platform with RWS’s existing security tools (e.g., EPP/EDR, firewalls/NDR, vulnerability scanners, identity platforms, email gateways, SaaS and cloud providers) to enable automated data exchange, enrichment, and coordinated response actions. | ||
| 928 | 5.8.12.3 Security workflows and processes shall be orchestrated end-to-end to ensure consistent, timely, and efficient handling of security incidents across the environment, with SLA timers, de-duplication windows, and ticket automation. | ||
| 929 | 5.8.13 Regular Review | ||
| 930 | 5.8.13.1 The MXDR shall perform scheduled, recurring reviews of user roles and access privileges across EPP/EDR/XDR, SOAR, and integrated tools. Any discrepancies or policy violations identified shall be reported to RWS with recommended corrective actions and due dates. | ||
| 931 | 5.8.13.2 The MXDR shall conduct periodic, comprehensive assessments of RWS’s overall security posture across endpoint and cross-domain controls, evaluating rule/configuration efficacy, telemetry completeness, response guardrails, and vulnerabilities, and shall provide actionable recommendations prioritized by risk and business impact. | ||
| 932 | 5.8.13.3 The MXDR shall provide support during internal and external security audits, including generation of required reports and evidence, demonstration of compliance with policies/regulations, and explanation of relevant security processes, content governance, and controls. | ||
| 933 | 5.8.13.4 The MXDR shall conduct periodic, comprehensive baseline and configuration adherence reviews across EPP/EDR/XDR and MXDR operations, including endpoint agent/sensor posture, connector health, schema/field mapping integrity, UEBA model drift, and playbook efficacy, and shall provide actionable recommendations with tracked remediation to improve security posture and operational resilience. | ||
| 934 | 5.8.14 Reporting | ||
| 935 | 5.8.15 The MXDR shall conduct regular reporting to RWS, including but not limited to monthly and quarterly security monitoring reports. These reports must provide comprehensive insights and cover the following elements: | ||
| 936 | a) Executive Summary | ||
| 937 | · Overview of the reporting period | ||
| 938 | · Key metrics (e.g., number of incidents, severity levels, resolution rates) | ||
| 939 | · Strategic highlights (e.g., improvements, emerging risks, compliance status) | ||
| 940 | · Summary of recommendations and next steps | ||
| 941 | b) Major Security Events and Activities | ||
| 942 | · Event Summary Table: | ||
| 943 | o Event type, date, severity, affected assets | ||
| 944 | · Narrative Overview: | ||
| 945 | o Description of major activities (e.g., threat hunting, forensic investigations) | ||
| 946 | o Notable changes in threat landscape or attack vectors | ||
| 947 | · Security Operations Metrics: | ||
| 948 | o Number of alerts processed | ||
| 949 | o Mean time to detect (MTTD) and mean time to respond (MTTR) | ||
| 950 | o Patch management and vulnerability remediation stats | ||
| 951 | c) Security Incident Details | ||
| 952 | · Incident Inventory: | ||
| 953 | o Classification (e.g., malware, phishing, insider threat) | ||
| 954 | o Description, timestamp, detection method | ||
| 955 | o Affected systems/users | ||
| 956 | · Incident Lifecycle Analysis: | ||
| 957 | o Timeline of detection, escalation, containment, and resolution | ||
| 958 | o Root cause and contributing factors | ||
| 959 | · Impact Assessment: | ||
| 960 | o Business impact (e.g., downtime, data exposure) | ||
| 961 | o Regulatory or reputational implications | ||
| 962 | d) Resolution Status and Action Plans | ||
| 963 | · Status Dashboard: | ||
| 964 | o Resolved, in-progress, escalated, false positives | ||
| 965 | · Actions Taken: | ||
| 966 | o Technical remediation steps | ||
| 967 | o Policy or process changes | ||
| 968 | · Recommendations: | ||
| 969 | o Preventive measures | ||
| 970 | o Training or awareness initiatives | ||
| 971 | o Technology upgrades | ||
| 972 | e) Optimization and Improvement Opportunities | ||
| 973 | · Security Posture Review: | ||
| 974 | o Gaps identified in detection, response, or governance | ||
| 975 | · Process Improvement Suggestions: | ||
| 976 | o Automation opportunities | ||
| 977 | o Incident response playbook enhancements | ||
| 978 | o Use case reviews | ||
| 979 | · Technology Recommendations: | ||
| 980 | o Tool tuning, integrations, or replacements | ||
| 981 | · Lessons Learned: | ||
| 982 | o Case studies from incidents | ||
| 983 | o Best practices for future prevention | ||
| 984 | f) Threat Intelligence Contextualized to RWS | ||
| 985 | · Threat Landscape Overview: | ||
| 986 | o Global and regional trends | ||
| 987 | o Industry-specific risks | ||
| 988 | · Contextual Intelligence: | ||
| 989 | o Threats targeting hospitality, entertainment, or infrastructure | ||
| 990 | o Actor profiles and tactics, techniques, and procedures (TTPs) | ||
| 991 | · Indicators of Compromise (IOCs): | ||
| 992 | o Relevant IOCs observed in RWS’s environment | ||
| 993 | · Forecasting & Early Warning: | ||
| 994 | o Anticipated threats based on intelligence feeds and analytics | ||
| 995 | g) Compliance and Governance | ||
| 996 | · Regulatory Alignment: | ||
| 997 | o Status against frameworks (e.g., PDPA, ISO 27001) | ||
| 998 | · Audit Findings and Remediation: | ||
| 999 | o Summary of internal/external audits | ||
| 1000 | o Remediation progress | ||
| 1001 | · Policy Updates: | ||
| 1002 | o Changes to security policies or procedures | ||
| 1003 | h) Appendices | ||
| 1004 | · Charts, graphs, and dashboards | ||
| 1005 | · Glossary of terms | ||
| 1006 | · Supporting documentation (e.g., logs, screenshots, reports) | ||
| 1007 | 5.8.15.1 The MXDR shall provide the following reports to RWS on a scheduled or event-driven basis, as applicable: | ||
| 1008 | 5.8.15.1.1 Incident Reports: Detailed documentation for each security incident, including timeline, impact analysis, response actions, and resolution status. | ||
| 1009 | 5.8.15.1.2 Threat Hunting Reports: Findings and insights from proactive threat hunting activities conducted across RWS’s environment. | ||
| 1010 | 5.8.15.1.3 Role and Access Review Reports: Periodic reports detailing user roles, access privileges, anomalies, and policy violations. | ||
| 1011 | 5.8.15.1.4 Security Landscape Review Reports: Comprehensive assessment of RWS’s security posture, including control effectiveness and improvement recommendations. | ||
| 1012 | 5.8.15.1.5 System or Solution Platform Health and Performance Reports: Metrics and analysis related to system performance, resource utilization, and operational status. | ||
| 1013 | 5.8.15.1.6 Customized Dashboards and Alert Definitions: Tailored visualizations and alert configurations aligned with RWS’s operational needs. | ||
| 1014 | 5.8.15.1.7 Incident Response Playbooks and Runbooks: Updated documentation outlining procedures for responding to various types of security incidents. | ||
| 1015 | 5.8.15.1.8 Recommendation for Security Posture Improvement: Actionable guidance based on monitoring, analysis, and review activities to enhance RWS’s overall security maturity. | ||
| 1016 | 5.8.15.2 All standard reports shall be submitted to RWS within five (5) working days from the start of each calendar month. | ||
| 1017 | 5.8.15.3 Management and Executive-level reports shall be delivered on a quarterly basis, providing strategic insights and summaries tailored for senior stakeholders. | ||
| 1018 | 5.8.16 Managed MXDR Support Services | ||
| 1019 | 5.8.16.1 The MXDR Supplier shall allocate up to one hundred twenty (120) hours annually to support service requests, utilizing suitably qualified and experienced personnel. Any unused hours within a contract year may roll over to the next contract year, up to a maximum cumulative cap of two hundred forty (240) hours at any given time. Unused hours exceeding this cap shall automatically lapse unless otherwise approved in writing by RWS IT. These hours shall be dedicated to additional operational-management activities within the Managed MXDR service scope, which may include but are not limited to: | ||
| 1020 | • Architectural modifications and system modifications | ||
| 1021 | • Onboarding of custom log sources | ||
| 1022 | • Security consultancy | ||
| 1023 | • Firmware or software upgrades | ||
| 1024 | • Development of complex or customized use cases | ||
| 1025 | • Other related enhancements as required by RWS IT | ||
| 1026 | 5.8.16.2 The MXDR service shall incorporate EPP, EDR, and XDR capabilities to deliver unified detection, investigation, and response coverage across all log sources and endpoints specified in this tender. | ||
| 1027 | 5.8.16.3 The Tenderer shall ensure uninterrupted monitoring and full operational readiness throughout the transition period and shall submit a Transition Plan detailing milestones, onboarding activities, and risk-mitigation measures for RWS’s approval prior to commencement. | ||
| 1028 | 5.9 Software and Licenses | ||
| 1029 | 5.9.1 The subscription shall include EPP/EDR endpoint licensing for seven thousand five hundred (7,500) endpoints (Windows / macOS / Linux workstations and servers, including persistent and non-persistent VDI instances and containerized workloads, with the ability to co-term and true-up / true-down seats in accordance with RWS’s asset changes and growth License true-up or true-down shall be conducted quarterly. The subscription shall remain valid for the Contract Period of three (3) years, and an option to extend for up to two (2) additional one-year terms (3+1+1), subject to RWS’s written approval and performance review. | The licenses (includes online services) shall be fulfilled through RWS’s existing Microsoft Volume Licensing contracts below: EA – For online services and licenses for end-user. Enrollment number : 50008390 Enrollment period : 1 Jan 2025 – 31 Dec 2027 Midterm True-up can happen any time within the enrollment period. True-down can only happen at the enrollment anniversary. SCE/MACC – For online services fulfilled through Azure. Enrollment number : 65672117 Enrollment period : 1-Aug-2025 – 31-Jul-2028 Validity of pricing is aligned to the enrollment period. The delivery shall be governed by the Microsoft Volume Licensing program rules, includes contracts signed between RWS and MSFT. | |
| 1030 | 5.9.2 The platform shall include a minimum of 90 days of online, hot searchable data for EPP prevention events (e.g., blocks, quarantine, tamper), EDR telemetry and detections (e.g., process/file/registry, network/DNS, auth, script/AMSI, memory injection where supported), and XDR normalized incidents and events; search shall be available via UI and API without per-search throttling at stated volumes. | Microsoft Defender XDR APIs have specific throttling limits, with the Advanced Hunting API limiting searches to 45 calls per minute. | |
| 1031 | 5.9.3 The supplier shall provide annual education credits that enable 10 RWS personnel to participate in training courses at no cost to RWS. These courses shall cover EPP administration, EDR investigations and threat hunting, XDR correlation, UEBA, query language usage, and SOAR/playbook developments. The entitlement shall also include opportunities for participants to earn professional certifications as part of their yearly learning benefits. | ||
| 1032 | 5.9.4 All license fees payable by RWS (including EPP/EDR/XDR software, connectors, and MXDR service subscriptions) shall only become chargeable and enforceable after completion of the Functional and/or Design Specification and subsequent formal sign-off, subject to prior written authorization from RWS. | ||
| 1033 | 5.9.5 The Supplier shall provide tiered pricing for incremental storage and retention (size and duration) and for incremental ingest (EPS/GB-per-day) and endpoint counts. Tiers shall include unit pricing for hot/warm/cold retention, archival retrieval, connector add-ons (if any), and committed use or multi-year discounts. Pricing must clearly state any overage rates and the conditions for burst headroom. | Prices are fixed in accordance with the concession price given by Microsoft. | |
| 1034 | 5.9.6 The subscription shall grant access to content and use-case entitlements without restrictions on the number of prevention policies (EPP), detection rules and hunts (EDR), and correlation rules/UEBA models, and SOAR playbooks (XDR), subject to platform capabilities and RWS approved workflow. The supplier is required to provide a catalogue and a change log for all deployed content. | ||
| 1035 | 5.10 Hardware | ||
| 1036 | 5.10.1 All solution components shall comply with RWS standards for system compatibility, platform interoperability, and integration with existing RWS monitoring and management tools. No new physical hardware procurement is required under this tender. | ||
| 1037 | 5.11 System Integration | ||
| 1038 | As set out in Section 20 of this Appendix B1. | ||
| 1039 | 5.12 Acceptance Tests | ||
| 1040 | As set out in Section 11 of this Appendix B1 | ||
| 1041 | 5.13 System Training and Knowledge Transfer | ||
| 1042 | As set out in Section 14 of this Appendix B1. | ||
| 1043 | 5.14 Project Documentation and Deliverables | ||
| 1044 | As set out in Sections 6.2 and 6.3 of this Appendix B1. | ||
| 1045 | 5.15 Performance Guarantee Period, Warranty, and Maintenance Services | ||
| 1046 | As set out in Sections 13, 15, and 16 of this Appendix B1. | ||
| 1047 | 6. Timeline, DOCUMENTATION and deliverables | ||
| 1048 | 6.1 Timeline | ||
| 1049 | 6.1.1 The Supplier shall deliver the System according to the following key milestones, and these key milestones may be amended or further expanded in detail in a mutually agreed Project Plan : | ||
| 1051 | 6.1.2 The Supplier shall be wholly responsible for the timely delivery of the System. | ||
| 1052 | 6.2 Documentation | ||
| 1053 | 6.2.1 The Supplier shall provide sufficient documentation and training manuals (the “Documentation”) as part of the deliverables stipulated in Section 6.3 below at no additional cost to the Company. | ||
| 1054 | 6.2.2 The Supplier shall provide all Documentation in English and expressed in clear, consistent, readily understandable language and defined terms. | ||
| 1055 | 6.2.3 The Supplier shall provide one (1) set (soft copy) of the approved version of Documentation to the Company. | ||
| 1056 | 6.2.4 The Company reserves the right to reproduce any Documentation supplied for its own internal use. | ||
| 1057 | 6.2.5 The Supplier shall provide the latest version of all Documentation, or where requested, the version specified by the Company. | ||
| 1058 | 6.2.6 The Supplier shall establish a proper document change procedure to keep track of the changes made to the Documentation, the reasons for the change, the date of the Documentation was last updated and the name of the personnel who made the last update. Proper records of the different versions of the Documentation have to be maintained. | ||
| 1059 | 6.2.7 The Supplier shall provide draft versions of the Documentation for the Company’s review before delivering the final version of the Documentation to the Company for approval. The Supplier shall cater for at least one (1) week for each review. | ||
| 1060 | 6.2.8 The Company shall accept the final version of the Documentation, after all the corrections have been made and after all amendments required by the Company have been incorporated into the Documentation by the Supplier. | ||
| 1061 | 6.3 Deliverables | ||
| 1062 | The Supplier shall provide complete detailed and adequate documentation in alignment with RWS IT Project Delivery Framework (where required and/or applicable, for each batch of Acceptance Tests), but shall not limited to, the sign-off of the following deliverables : | ||
| 1063 | 6.3.1 Project Management deliverables: | ||
| 1064 | 6.3.1.1 Project Plan | ||
| 1065 | 6.3.1.2 Project Deliverables & Schedule | ||
| 1066 | 6.3.1.3 Statement of Work (Project Scope) | ||
| 1067 | 6.3.1.4 Project Risk, Issue and Change Logs | ||
| 1068 | 6.3.1.5 Deployment Plan | ||
| 1069 | 6.3.2 Requirement deliverables: | ||
| 1070 | 6.3.2.1 Functional Requirements Specifications | ||
| 1071 | 6.3.2.2 Non Functional Requirements Specifications | ||
| 1072 | 6.3.2.3 Integration Requirements Specifications | ||
| 1073 | 6.3.3 Analysis and Design deliverables: | ||
| 1074 | 6.3.3.1 Architecture & Technical Specifications & Diagram | ||
| 1075 | 6.3.3.2 Application, UI & Report Design Specifications | ||
| 1076 | 6.3.3.3 Tuning Report | ||
| 1077 | 6.3.3.4 Logical Database Model | ||
| 1078 | 6.3.3.5 Data Conversion and Migration Design | ||
| 1079 | 6.3.4 Installation & Configuration deliverables: | ||
| 1080 | 6.3.4.1 Environment Configuration Baseline | ||
| 1081 | 6.3.4.2 Deployment Guide | ||
| 1082 | 6.3.4.3 Operations Guide | ||
| 1083 | 6.3.4.4 Backup, Failover & Recovery Guide | ||
| 1084 | 6.3.4.5 Housekeeping Configuration Baseline (logs, files & data) | ||
| 1085 | 6.3.4.6 Source code | ||
| 1086 | 6.3.5 Testing deliverables: | ||
| 1087 | 6.3.5.1 SIT Test Strategy and Plan, Test Scenarios and Test Cases, Requirement Traceability Matrix (RTM), Defect/Issue Logs and Fixes and Test Summary & Report | ||
| 1088 | 6.3.5.2 UAT Test Strategy and Plan, Test Scenarios and Test Cases, Requirement Traceability Matrix (RTM), Defect/Issue Logs and fixes , Test Summary & Report | ||
| 1089 | 6.3.5.3 Performance Test Strategy and Plan, Test Scenarios and Test Cases, Defect/Issue Logs and Fixes, Test Summary & Report | ||
| 1090 | 6.3.5.4 High Availability (HA) Test Plans, Test Scenarios and Test Cases, Defect/Issue Logs and Fixes Test Summary & Report | ||
| 1091 | 6.3.5.5 Disaster Recovery (DR) Test Plans, Test Scenarios and Test Cases, Defect/Issue Logs, Test Summary & Report | ||
| 1092 | 6.3.5.6 ORT Test Plans, Test Scenarios and Test Cases, Defect/Issue Logs and Fixes, Test Summary & Report | ||
| 1093 | 6.3.6 Training deliverables: | ||
| 1094 | 6.3.6.1 Training Slides | ||
| 1095 | 6.3.6.2 Training Hand-outs | ||
| 1096 | 6.3.6.3 Quick Start Guides (How-To) | ||
| 1097 | 6.3.6.4 Frequently Asked Questions (FAQ) | ||
| 1098 | 6.3.7 Miscellaneous deliverables | ||
| 1099 | 6.3.7.1 Function to Role Mapping Document | ||
| 1100 | 6.3.7.2 List of Admin/Super User Accounts Document | ||
| 1101 | 6.3.7.3 Performance Certification Document | ||
| 1102 | 6.3.7.4 User Guides | ||
| 1103 | 6.3.7.5 Administrator Guides | ||
| 1104 | 6.3.7.6 Data Provider Change Guide | ||
| 1105 | 6.3.8 Miscellaneous documents (E.g. Release Notes, APIs documents, etc.) | ||
| 1106 | 6.3.9 Support | ||
| 1107 | 6.3.9.1 Technical Support, Escalation Matrix & Contact Information | ||
| 1108 | 6.3.10 Managed Security Services | ||
| 1109 | 6.3.10.1 Monthly and Quarterly Security Monitoring Reports | ||
| 1110 | 6.3.10.2 Incident Reports (per incident) | ||
| 1111 | 6.3.10.3 Threat Hunting Reports (as conducted) | ||
| 1112 | 6.3.10.4 Role and Access Review Reports (periodically) | ||
| 1113 | 6.3.10.5 Use Case Review and Improvement Recommendations (periodically) | ||
| 1114 | 6.3.10.6 Configuration Baseline Review and Recommendations Report (periodically) | ||
| 1115 | 6.3.10.7 Security Landscape Review Reports (periodically) | ||
| 1116 | 6.3.10.8 System or Solution Platform Health and Performance Reports | ||
| 1117 | 6.3.10.9 Customized Dashboards and Alert Definitions | ||
| 1118 | 6.3.10.10 Incident Response Playbooks and Runbooks (as updated) | ||
| 1119 | 6.3.10.11 Recommendations for Security Posture Improvement | ||
| 1120 | 7. General dependencies and assumptions | ||
| 1121 | 7.1 The System shall be scalable for future requests from the Company to support the expansion of coverage of security monitoring use cases, log sources and telemetry ingestion to the System. | ||
| 1122 | 8. DELAY IN SUPPLY, PURCHASE FROM OTHER SOURCES AND LIQUIDATED DAMAGES | ||
| 1123 | 8.1 Time shall be of the essence in this LOA. The Supplier undertakes to install, implement and commission the System no later than the stipulated Commissioning Date (as defined at Section 12.1 of Appendix B1) specified in Section 6.1.1 or the Project Plan as accepted by Company. | ||
| 1124 | 8.2 In the event the Supplier fails to supply any item of the Goods and/or Services by the date and to the location specified in the LOA and/or Purchase Order; or the System fails to meet the stipulated Commissioning Date, the Company shall, in addition to any other remedies which it may have under the LOA or otherwise have the right to: | ||
| 1125 | 8.2.1 Cancel all or any such items of the Goods / Services without being liable for damages and obtain the same Goods/ Services from other sources. In the event additional costs are incurred by virtue of this Section 8.2.1, all such costs incurred shall be deducted from any monies due to or may become due to the Supplier under the LOA, or shall be recoverable as damages; | ||
| 1126 | 8.2.2 Require the Supplier to pay or to deduct from the total price payable for all of the delayed Goods / Services, as liquidated damages (and not as a penalty), a sum to be calculated at the rate of 1% of the total contract value, per calendar day (including Public Holidays) from the date of default to the actual day where the delayed Goods and/or Services are delivered to Company, subject to a maximum amount equal to 10% of the of the total contract value (“Maximum LD for Delay”). For the avoidance of doubt, the Maximum LD for Delay applies to each event of delay committed by the Supplier; or | ||
| 1127 | 8.2.3 Terminate the LOA in accordance with Clause 27 of Appendix A1. | ||
| 1128 | 8.3 If the Supplier is unable to carry out Services in accordance with this LOA or fails to perform and observe any of its obligations within a specified timescale or agreed critical date (either of which are referred to in this Section as the "Relevant Failure”) then, without reducing or affecting any other right or remedy which Company may have under this LOA or otherwise, Company shall be entitled to any or all of the following: | ||
| 1129 | 8.3.1 Receive the SLA Compensation in the manner, quantum and on the conditions stipulated in this Appendix, to be computed on a monthly basis; | ||
| 1130 | 8.3.2 Suspend payment of any amounts then due and any which may subsequently become due to Supplier under this LOA until such time as Supplier remedies the Relevant Failure; | ||
| 1131 | 8.3.3 Terminate forthwith the provision of Services provided by the Supplier which are affected by the Relevant Failure (in which case notice shall only be valid if made in writing signed by an authorised representative of Company); | ||
| 1132 | 8.3.4 Obtain the Services from a third party service provider and the Supplier is to render full support in respect thereof including but not limited to the provision of assistance in transitioning any obligations or services to the third party service provider at no additional cost to Company; and/or | ||
| 1133 | 8.3.5 Terminate the LOA with immediate effect by written notice without prejudice to the Company’s other rights and remedies. | ||
| 1134 | 8.4 If the Company chooses to exercise its rights under Section 8.3.3 or 8.3.4 or 8.3.5 above, the Supplier shall refund to Company on a pro rata basis any monies paid by Company in advance for the Services beyond the date of termination. | ||
| 1135 | 9. REMOVAL AND REPLACEMENT OF REJECTED GOODS | ||
| 1136 | 9.1 The Supplier shall, when so required by the Company, remove and replace within seven (7) days and at his own expense, any Goods / Services which are found on delivery to be damaged, defective or in any way inferior to approved samples or not in accordance with the Company’s requirements, failing which the Company shall have the right to purchase replacements elsewhere or to make good any damage in any manner it deems fit and all costs thereby incurred shall be deducted from any monies due or to become due to the Supplier under the LOA or shall be recoverable as damages. | ||
| 1137 | 10. DELIVERY | ||
| 1138 | 10.1 The Goods shall be free from any liens and encumbrances. The title in the Goods and any part thereof shall pass to the Company upon delivery. | ||
| 1139 | 10.2 The Supplier shall confirm the actual delivery date and time in writing with the Company no less than seven (7) days before the actual delivery date. | ||
| 1140 | 10.3 Any incomplete delivery by the Supplier shall be regarded as non-delivery of the Goods unless accepted by the Company in writing. | ||
| 1141 | 10.4 The Company shall for the purposes of the LOA, procure access to the Site or afford access to the Site to the authorized personnel of the Supplier during normal business hours. | ||
| 1142 | 10.4 The Company shall for the purposes of the LOA, procure access to the Site or afford access to the Site to the authorized personnel of the Supplier during normal business hours. | ||
| 1143 | 11.1 “Acceptance Tests” means all tests as listed in this section, or otherwise as agreed to in writing between the parties to be conducted on the System in accordance with this section. | ||
| 1144 | 11.2 The Acceptance Tests are carried out to verify and demonstrate that the System meets the requirements as set out in this LOA. The Supplier shall not commence work on any Acceptance Test(s) without first obtaining the Company’s prior written approval to do so. For each of and every individual Acceptance Test, the Supplier shall submit a comprehensive test plan, acceptance criteria and procedure to the Company for its prior review and approval. Submission must be made at least one (1) week prior to the actual conduct of each test. | ||
| 1145 | 11.3 After installation of the Goods or part thereof, the Supplier shall conduct Acceptance Tests on all the Goods to verify and demonstrate that the Goods meet the requirements of this LOA. | ||
| 1146 | 11.4 The Supplier shall provide at its own costs, all tools and testing equipment for the purposes of the Acceptance Tests. | ||
| 1147 | 11.5 Upon completion of any Acceptance Test, the Supplier shall give written notice of such completion to the Company. If the Company is satisfied that the Acceptance Test has been successfully completed, the Company shall certify accordingly by signing off on the relevant reports (“Sign-Off”). If the Company is not satisfied that the Acceptance Test has been successfully completed, the Company shall, within a period of thirty (30) days of receipt of the notice, issue a report of defects to the Supplier. | ||
| 1148 | 11.6 For the purposes of Acceptance Tests, definition of the defects severity level are set out below: | ||
| 1149 | Defects | ||
| 1150 | 11.7 If any part of the System fails to pass the Acceptance Test (or any repeat Acceptance Tests, if any) or does not operate in compliance with this LOA, and/or the documentation does not fully and accurately describe in reasonable detail the operation, features and functionality of the System (a “Failure”), of which the Company shall be the sole judge, then the Company may, by written notice to the Supplier elect one (1) of the following options at its sole discretion: | ||
| 1151 | 11.7.1 To have the Supplier provide a solution (including the replacement of any Goods if necessary without charge to Company) and to fix (without prejudice to the Company’s other rights and remedies) a new date for carrying out further tests on the System on the same terms and conditions, save that all costs which the Company may incur as a result of carrying out such tests shall be reimbursed by the Supplier. Unless otherwise agreed in writing between the Parties, all such further tests shall not be construed as any grant of extension of time by the Company and the Supplier remains liable for any delay in complying with its obligations under the LOA; or | ||
| 1152 | 11.7.2 To conditionally accept the System or any part thereof at the Company’s absolute discretion. The conditions of acceptance shall be as the Company may reasonably determine. If so agreed by the parties in writing, conditional acceptance shall constitute acceptance of the System or the relevant part thereof provided that all the relevant conditions have been met within the period specified by the Company. If all the relevant conditions have not been met within the period specified by the Company, then the Company shall be entitled to proceed under Section 11.7.3 below; or | ||
| 1153 | 11.7.3 To treat the Supplier as being in breach of the LOA and to reject the System as not being in conformity with the LOA, in which event the Company shall be entitled to terminate this LOA (without prejudice to the Company’s other rights and remedies) in accordance with Clause 28 of Appendix A1 to this LOA. | ||
| 1154 | 11.8 Installation Test | ||
| 1155 | 11.8.1 At the conclusion of the System installation, a preliminary walk-through with the Company must be performed to check for installation quality, accurate performance of the work and to verify workflow diagrams if there is any. Any modifications to the documentation or the installation that may be required must be accomplished within one (1) week from the identification of the problem. | ||
| 1156 | 11.8.2 When the System has successfully passed the installation tests, the Supplier shall so certify to the Company in writing that the System is operating in accordance with the LOA. The date of such certification shall be the Installation Date. The issuance of such certificate shall be without prejudice to the Company’s right to reject the System pursuant to Clause 28 of Appendix A1 to this LOA. | ||
| 1157 | 11.9 System Integration Test | ||
| 1158 | 11.9.1 The System Integration Test (“SIT”) must commence only after the System has been completely installed with all the components and successfully completed customization in development environment by the Supplier. | ||
| 1159 | 11.9.2 The objective of the SIT is to test and ensure that all components of the System are working end-to-end as intended before the User Acceptance Test. This includes all customization, hardware integration, integration with other systems and data loading. | ||
| 1160 | 11.9.3 The Supplier must supply all test plans, test script, requirement traceability matrix (RTM), test data, equipment, connections and skilled labour required for the test results without additional charge to the Company. | ||
| 1161 | 11.9.4 With advice and assistance of the Supplier, the Company shall operate the System for a specified period, such period to be agreed in accordance with Section 6.1.1 above to: | ||
| 1162 | 11.9.4.1 perform the Company’s routine transactions; | ||
| 1163 | 11.9.4.2 carry out System functions test to determine whether the System meets the requirements in this LOA; and | ||
| 1164 | 11.9.4.3 carry out integration testing to determine whether interface between system to system meet all deliverables in this LOA. | ||
| 1165 | 11.9.5 The exit criteria for SIT are: | ||
| 1166 | 11.9.5.1 All SIT test scenarios have been executed successfully; | ||
| 1167 | 11.9.5.2 No outstanding Medium Defects and High Defects; and | ||
| 1168 | 11.9.5.3 Resolution and workaround agreed for other outstanding defects. | ||
| 1169 | 11.10 User Acceptance Test | ||
| 1170 | 11.10.1 The User Acceptance Test (“UAT”) must commence only after: | ||
| 1171 | 11.10.1.1 the System has been completely installed with all the components and successfully completed the SIT by the Supplier; and | ||
| 1172 | 11.10.1.2 the SIT has met the exit criteria set out in Section 11.9.5 above. | ||
| 1173 | 11.10.2 The objective of the UAT is for the Company’s business users to verify that all components of the System are working end-to-end as intended to facilitate sign off of acceptance of the System. This includes all customisation, hardware integration, integration with other systems and data loading. | ||
| 1174 | 11.10.3 The UAT should be performed on the System completely installed with all the components supplied by the Supplier under this LOA, and in the UAT environment of the System. | ||
| 1175 | 11.10.4 The Supplier must supply all test plans, scenarios, test script, requirement traceability matrix (RTM), test data, equipment, connections and skilled labour required for the test results without additional charge to the Company. | ||
| 1176 | 11.10.5 With the advice and assistance of the Supplier, the Company shall operate the System for a specified period, such period to be agreed in accordance with Section 6.1.1 above, to: | ||
| 1177 | 11.10.5.1 Perform the Company’s routine transactions; | ||
| 1178 | 11.10.5.2 Perform the transactions performed during any benchmark tests or other Supplier demonstrations included, referenced, or incorporated in this LOA; | ||
| 1179 | 11.10.5.3 Carry out System functions test to determine whether the System meets the specifications, performs the functions and meets the criteria for System Availability, System Performance, Response Time; | ||
| 1180 | 11.10.5.4 Determine whether the documentation for the System meets the requirements of this Project; and | ||
| 1181 | 11.10.5.5 Perform such other transactions as may be necessary to test the System Performance. | ||
| 1182 | 11.10.6 The exit criteria for UAT are: | ||
| 1183 | 11.10.6.1 All UAT Test Scenarios have been executed successfully; | ||
| 1184 | 11.10.6.2 No outstanding Medium Defects and High Defects; and | ||
| 1185 | 11.10.6.3 Resolution and workaround agreed for other outstanding defects. | ||
| 1186 | 11.11 Operational Readiness Test | ||
| 1187 | 11.11.1 The Operation Readiness Test (“ORT”) must commence only after: | ||
| 1188 | 11.11.1.1 The System has been completely installed with all the components supplied by the Supplier under this LOA; and | ||
| 1189 | 11.11.1.2 The UAT has met the exit criteria set out in Section 11.10.6 above. | ||
| 1190 | 11.11.2 The ORT shall be performed in the production system environment set up at the Company’s resort premises. | ||
| 1191 | 11.11.3 The Supplier must supply all the test plans, scenarios, test script, test data, equipment, connections and skilled labour required for the provision and submission of test results without additional charge to the Company. | ||
| 1192 | 11.11.4 With the advice and assistance of the Supplier, the Company shall operate the System for a specified period, such period to be agreed in accordance with Section 6.1.1 above, to: | ||
| 1193 | 11.11.4.1 Perform Company’s routine transactions; | ||
| 1194 | 11.11.4.2 Perform the transactions performed during any benchmark tests or other Supplier demonstrations included, referenced, or incorporated in this LOA; | ||
| 1195 | 11.11.4.3 Carry out System functions test to determine whether the System meets the specifications, performs the functions and meets the criteria for Systems Availability, System Performance, System Response Time; | ||
| 1196 | 11.11.4.4 Determine whether the documentation for the System meets the requirements of this Project; and | ||
| 1197 | 11.11.4.5 Perform such other transactions as may be necessary to test the System Performance as specified in this LOA. | ||
| 1198 | 11.11.5 The exit criteria for ORT are: | ||
| 1199 | 11.11.5.1 All acceptance criteria are met; | ||
| 1200 | 11.11.5.2 No outstanding Medium Defects and High Defects; and | ||
| 1201 | 11.11.5.3 Resolution and workaround agreed for other outstanding defects. | ||
| 1202 | 11.12 Performance Test | ||
| 1203 | 11.12.1 The purpose of the performance test is to demonstrate conformance to requirements for the performance of the System as specified in Section 17.10 below. | ||
| 1204 | 11.12.2 Performance tests shall be performed under normal and full load. The Supplier shall propose how to generate the transaction loads accordingly in order to test the System as though operating under live conditions, including the provision of all necessary performance testing and load generation tools. | ||
| 1205 | 11.12.3 The Supplier shall also propose the test coverage, the type of testing services and the amount of load to be generated on the System and application, which are subject to the prior approval of the Company, and will need to be according to the business requirements of Company, the size of the Company user base, the number of concurrent users, the application architecture, the system configuration and related attributes including latency and round trip timings. | ||
| 1206 | 11.12.4 The performance test shall be performed for the System after UAT prior to the commissioning of the System. However, performance test shall be allowed to start earlier if the need arises (subject to the Company’s prior approval). | ||
| 1207 | 11.12.5 The performance test shall be performed using the production and UAT server hardware, system software, application software and all other components required by the System, and production clients at the Company’s premises. In the event that it is not possible to utilize the production server for such tests, the Supplier shall propose how the performance test can be conducted. | ||
| 1208 | 11.12.6 The Supplier must be able to show that the performance test has been carried out and the System is ready for the Company’s review. | ||
| 1209 | 11.12.7 The Company shall confirm if the System meets the performance requirements as defined in Section 17.10 below. If the System does not meet the performance requirements, the Supplier shall propose corrective actions that will be undertaken to meet performance requirements. | ||
| 1210 | 11.13 Failover Test | ||
| 1211 | 11.13.1 Supplier shall advise on how the Failover Test (“FO”) will be conducted. | ||
| 1212 | 11.13.2 The FO must commence only after the System has been completely installed with all the components proposed in production environment by the Supplier. | ||
| 1213 | 11.13.3 The FO shall be performed in the production system environment set up with its clients at the Company’s resort premises. | ||
| 1214 | 11.13.4 The Supplier must supply all the test plans, scenarios, test script, test data, equipment, connections and skilled labour required for the provision and submission of test results without additional charge to the Company. | ||
| 1215 | 11.13.5 With the advice and assistance of the Supplier, the Company shall operate the System for a specified period, such period to be agreed in accordance with Section 6.1.1 above, to perform failover and failback according to the procedure with minimum interruption. | ||
| 1216 | 11.14 High Availability and Disaster Recovery Tests | ||
| 1217 | 11.14.1 Supplier shall advise on how High Availability and Disaster Recovery Tests (“HA and DR Tests”) will be conducted. | ||
| 1218 | 11.14.2 The HA and DR Tests must commence after the System has been completely installed with all the components proposed in production and DR environment by the Supplier. | ||
| 1219 | 11.14.3 The HA and DR Tests shall be performed in the production system environment set up with its clients at the Company’s resort premises. | ||
| 1220 | 11.14.4 The Supplier must supply all the test plans, scenarios, test script, test data, equipment, connections and skilled labour required for the provision and submission of test results without additional charge to the Company. | ||
| 1221 | 11.14.5 With the advice and assistance of the Supplier, the Company shall operate the System for a specified period, such period to be agreed in accordance with Section 6.1.1 above, to perform failover and failback according to the procedure with minimum interruption. | ||
| 1222 | 11.15 Penetration Test | ||
| 1223 | 11.15.1 The Supplier shall support RWS-initiated security validation or assurance activities (e.g., configuration review, log analysis, or security-control verification) prior to the Commissioning Date, as requested by RWS IT. No independent penetration testing is required under this tender. | ||
| 1224 | 12. Commissioning date | ||
| 1225 | 12.1 "Commissioning Date” means the date when the System has successfully been put to productive use after having successfully passed all Acceptance Tests for each Phase as set out in Section 5.1.2 (including the last Acceptance Test), and after the Company has signed off on all relevant documentation. | ||
| 1226 | 12.2 The Company shall issue a Commissioning Certificate in writing specifying the actual Commissioning Date after the following conditions are met: | ||
| 1227 | 12.2.1 The System has passed all Acceptance Tests and is fully integrated with the Company’s other systems, operational and stable; | ||
| 1228 | 12.2.2 Supplier has submitted to the Company all certification and test results as stated in this LOA; | ||
| 1229 | 12.2.3 No outstanding High and Medium Defects; and | ||
| 1230 | 12.2.4 The System has commenced business operations. | ||
| 1231 | 12.3 Notwithstanding the signing or issuance by the Company of any certificate or document or any payment in relation to the Goods and/or Services, the Supplier shall remain liable to Company under the terms and conditions of this LOA. | ||
| 1232 | 13. Performance guarantee period | ||
| 1233 | 13.1 The Performance Guarantee Period (“PGP”) shall commence on the Commissioning Date and shall continue for a period of three (3) months or until the System Acceptance Date (as defined at Section 13.5 below), whichever the later. | SWO to confirm | |
| 1234 | 13.2 During the PGP, the Supplier shall: | ||
| 1235 | 13.2.1 Be entirely responsible for the functioning of the System in accordance with the requirements in this LOA, and for the compliance of any additional requirements as may be necessary and only when mutually agreed upon between the Company and the Supplier at no additional cost to the Company; and | SWO to confirm | |
| 1236 | 13.2.2 Provide maintenance services during Support Hours (as defined in Section 16.4.2.2 below). | ||
| 1237 | 13.3 The System is deemed to have successfully completed the PGP if the System meets the following PGP completion criteria: | ||
| 1238 | 13.3.1 Comply with System Availability, System Reliability and System Performance for each calendar month or part thereof during the PGP (the Supplier shall maintain daily records for this purpose); | ||
| 1239 | 13.3.2 No outstanding High and Medium Defects; | ||
| 1240 | 13.3.3 Completion of Training and Knowledge Transfer as set out in Section 14 below; and | ||
| 1241 | 13.3.4 Completion of Documentation in accordance with the requirements as set out in Section 6.2 above. | ||
| 1242 | 13.4 Where the PGP completion criteria as set out in Section 13.3 are not met, Company reserves the right to extend the PGP on a monthly basis up to a maximum of six (6) months (inclusive of the initial three (3) months in Section 13.1) from the Commissioning Date. | ||
| 1243 | 13.5 Upon successful completion of the PGP completion criteria, the Company shall issue a written notice to the Supplier to accept the System. The date of the notice or the date when such notice should be issued as determined from the records kept (if different from the date of the notice) shall be the “System Acceptance Date”. | ||
| 1244 | 14. Training and knowledge transfer | ||
| 1245 | 14.1 General | ||
| 1246 | 14.1.1 The Supplier shall provide suitable and adequate customized training for Company’s appointed personnel to enable them to use and carry out competent operation and management of the System: | ||
| 1248 | 14.1.2 The Company reserves the right to revise the number of training sessions and number of users attending the training sessions to meet the Company’s operation requirements, and select, omit or alter at any time the whole or part of the training scope based on the cost submitted. | ||
| 1249 | 14.2 Training Environment | ||
| 1250 | 14.2.1 The Supplier shall use one of the environments as the training environment of the System and be responsible for setting up the training environment, which shall simulate the live production System. The setting up of the training environment shall include the setting up and configuring of all the training workstations, where applicable. | ||
| 1251 | 14.2.2 The Supplier shall conduct training courses at the location(s) to be specified by the Company. | ||
| 1252 | 14.3 Training Materials | ||
| 1253 | 14.3.1 The Supplier shall prepare all the training materials (including but not limited to the instructor’s guide, presentation slides, trainee’s booklet, and user guides). Such materials shall be submitted to the Company for approval at least one (1) week before the commencement of the training. Such materials shall form part of the Documentation. | ||
| 1254 | 14.3.2 The Supplier shall update the training materials in accordance with changes to the System. | ||
| 1255 | 15. WARRANTY | ||
| 1256 | 15.1 As part of the Goods/Services rendered under this LOA, the Supplier shall provide the Company with a Warranty for the Goods/Services and the results of the Goods/Services supplied. | SWO to confirm | |
| 1257 | 15.2 “Warranty” means the obligation of the Supplier to rectify any defects, errors and/or faults in the manner detailed in this section. | SWO to confirm | |
| 1258 | 15.3 The Warranty shall commence on the System Acceptance Date and last for nine (9) calendar months (“Warranty Period”). Warranty shall be provided to the Company at no additional cost. | SWO to confirm | |
| 1259 | 15.4 During the Warranty Period, the Supplier shall: | ||
| 1260 | 15.4.1 Adhere to the Service Level Agreement as specified in Section 17 below; | SWO to confirm | |
| 1261 | 15.4.2 Be entirely responsible for the satisfactory operation of the System at no additional cost to the Company; | SWO to confirm | |
| 1262 | 15.4.3 Render replacements (if supplied by the Supplier or otherwise attributable to the Supplier), investigations, services and any other works required to make good all defects at no cost to the Company; | SWO to confirm | |
| 1263 | 15.4.4 Perform corrective maintenance, troubleshooting and isolating defects, including but not limited to diagnosis and correction of all latent errors in the System due to configuration and customisation made by the Supplier. In the event of software defects, the Supplier shall work with the Company to provide possible workarounds to the Company; and | SWO to confirm | |
| 1264 | 15.4.5 Update all documents for changes to the System made by the Supplier. | SWO to confirm | |
| 1265 | 15.5 In the event that any stoppage of any function or facility occurs as a consequence of any fault or defect in the System occurring before or on the expiry of the Warranty Period, the Company reserves the right to overcome such faults by temporary patching if, at the Company’s sole discretion, such patching is necessary: | SWO to confirm | |
| 1266 | 15.5.1 Normal patches within five (5) working days; | SWO to confirm | |
| 1267 | 15.5.2 Critical patches within twenty four (24) hours. | SWO to confirm | |
| 1268 | Where necessary, the necessary details of the patches shall be submitted to the Supplier for verification and approval for patching thereafter. | SWO to confirm | |
| 1269 | 15.6 The Supplier verify the patches and submit a verification report to the Company as to whether patches provided to the Company are satisfactory within five (5) working days for normal patches; and within twenty four (24) hours for critical patches. In the event the patches are not satisfactory, the Supplier shall immediately rectify the faults and defects in the System causing the stoppage of functions or facilities. All such assessment, verification and rectification works done by the Supplier for this cause shall be performed without additional cost to Company. | SWO to confirm | |
| 1270 | 15.7 The Supplier shall ensure that the Services and results of the Services shall comply with or attain the Service Level Agreement as set out in Section 17 below during the term of the Warranty Period, failing which; compensation shall be given to the Company in accordance with Section 17.8 below. | SWO to confirm | |
| 1271 | 16. Maintenance | ||
| 1272 | 16.1 “Maintenance” means the preventive and/or corrective support services to be performed by the Supplier as set forth in this Section, and includes platform software maintenance, configuration updates, and managed-service sustainment activities. For clarity, no hardware maintenance is included under this Contract. | ||
| 1273 | 16.2 The Company shall have the option to engage the Supplier to provide Maintenance services for the duration of the Contract Period, comprising an initial three (3)-year term with two (2) optional one -year term extensions (3+1+1). Maintenance shall be performed in successive twelve (12)-month cycles aligned with each Contract year. | ||
| 1274 | For the avoidance of doubt, the Maintenance Services shall be co-termed and aligned with the Software License and Subscription Periods defined under 5.1.3. | ||
| 1275 | 16.3 Upon expiry of each Contract Year, any unused support hour or service credits may be carried forward to the next Contract Year, subject to mutual agreement during the annual service review. | ||
| 1276 | 16.4 The Supplier undertakes and warrants that: | ||
| 1277 | 16.4.1 Maintenance shall be provided in accordance with the Service Level Agreement; | ||
| 1278 | 16.4.2 The Supplier shall always maintain the necessary number of properly skilled, trained, qualified and experienced staff to enable the timely and efficient provision of Maintenance; | ||
| 1279 | 16.4.3 Throughout the Maintenance Period, the Supplier shall ensure that the System meets the System Availability and System Performance requirements. | ||
| 1280 | 16.4.4 Any Goods and/or Services provided during Maintenance: | ||
| 1281 | 16.4.4.1 Are and shall be fit for the purposes set out in this LOA. | ||
| 1282 | 16.4.4.2 Comply with the specifications and/or provisions in this LOA; and | ||
| 1283 | 16.4.4.3 Comply with any applicable regulations, statutes and laws of any competent authority; and | ||
| 1284 | 16.4.5 If the Company can demonstrate that performance of the System has been impaired by an act or omission of the Supplier or any agent of the Supplier, the Supplier shall, at its own expense, immediately take remedial action to restore such standard of performance as set out in this LOA. | ||
| 1285 | 16.5 Throughout the Maintenance Period, the Supplier shall provide the following types of Maintenance services to the Company : | ||
| 1286 | 16.5.1 Management of Incidents and Problems | ||
| 1287 | 16.5.1.1 The Supplier shall manage all incidents, problem, escalation and service resumption requirements in accordance with Section 17.4 below. | ||
| 1288 | 16.5.2 Support Model, Infrastructure and Support Hours | ||
| 1289 | 16.5.2.1 The Supplier shall describe and provide the support model and infrastructure in place locally or overseas to deliver Maintenance services to the Company. | ||
| 1290 | 16.5.2.2 “Support Hours” shall be defined as 0830 to 1800, Monday to Friday (excluding weekends and Public Holidays). | ||
| 1291 | 16.5.2.3 The Supplier shall provide uninterrupted Maintenance Services throughout the Support Hours. For any incidents/problems that are classified as P2 or higher, the Supplier shall provide support after the Support Hours in the event that the incident occurs out of the Support Hours. | ||
| 1292 | 16.5.3 System Maintenance | ||
| 1293 | 16.5.3.1 The Supplier shall provide support and assistance during the Company’s disaster recovery exercise to ensure that the System can be restored to operation. In the event the Company is unable to bring up the environment in the disaster recovery exercise, the Supplier will provide immediate assistance by diagnosing the problem and providing key steps to restart the application servers and servers. | ||
| 1294 | 16.5.3.2 The Company will raise the following types of Maintenance service requests to the Supplier which will include but is not limited to: | ||
| 1295 | 16.5.3.2.1 Support on ad-hoc data recovery | ||
| 1296 | 16.5.3.2.2 Request to build simple query for data extraction | ||
| 1297 | 16.5.3.2.3 Support on interface testing due to changes in sub-systems | ||
| 1298 | 16.5.3.2.4 Request for yearly evaluation on System performance & health check (Supplier to provide health checklist) | B2B support with MS? Or SoftwareOne to front? | |
| 1299 | 16.5.3.2.5 Request for Supplier to provide impact analysis on Microsoft security and System patches | ||
| 1300 | 16.5.3.2.6 Request for housekeeping scripts and steps to up keep System performance | ||
| 1301 | 16.5.3.2.7 Request for database re-index scripts to reduce database defragmentation and maintain overall System performance | ||
| 1302 | 16.5.3.3 The Supplier shall promptly deliver to the Company all necessary software update materials and documentation whenever new releases of the software are made available. | ||
| 1303 | 16.5.4 Hardware Maintenance | ||
| 1304 | 16.5.4.1 No hardware components or hardware maintenance form part of this Contract. All maintenance obligations apply to the XDR platform, software, and MXDR service. | ||
| 1305 | 17. Service Level Agreement | ||
| 1306 | 17.1 “Service Level Agreement” or “SLA” means the indicators and targets as set out in this section to govern the response and resolution time for Incidents and Problems logged by the Company. | ||
| 1307 | 17.2 “Problem” refers to the root cause of one or more Incident(s). | ||
| 1308 | 17.3 “Incident” refers to an unplanned interruption to the System, or reduction in the performance of the System. | ||
| 1309 | 17.4 Service Level Objectives (SLOs) are measurable performance targets that support the Service Level Agreement (SLAs) for the Solution. SLOs define the key technical baselines – such as availability, detection speed, and automated response – used to verify SLA compliance. Failure to meet any SLOs shall be considered an SLA breach and will be subject to the same compensation terms defined under Section 17.8 (SLA Compensation) | ORT/Commissioning and PGP completion will be based on functional correctness, defect exit criteria, documentation, and SLA process readiness. Performance observations will be reported but not guaranteed as SLO commitments | |
| 1311 | 17.5 Incident and Problem Management | ||
| 1312 | 17.5.1 The Supplier shall analyse the root causes of Incident/Problem reported, troubleshoot and isolate the Incident/Problem, including the diagnosis and correction of all latent errors in the System due to configurations and customisations. | ||
| 1313 | 17.5.2 The Supplier shall be responsible for end-to-end Incident and Problem management from the point when Incident/Problem is raised to closure, to: | ||
| 1314 | 17.5.2.1 Determine the type of Incident/Problem. | ||
| 1315 | 17.5.2.2 Determine the priority in consultation with the Company, | ||
| 1316 | 17.5.2.3 Liaise with the Company’s IT resources and external parties (e.g. Microsoft Support) when necessary. | ||
| 1317 | 17.5.2.4 Resolve and update the Incident with proper root cause analysis and resolution before closure. | ||
| 1318 | 17.5.2.5 Fix the Problem to permanently rectify the issue with proper documentation and testing, (or where the Problem is traced to the Software) work with the Company’s licensor to obtain the fix and test the same before releasing the fix to production; and | ||
| 1319 | 17.5.2.6 Update the Problem with proper root cause analysis and resolution before closure. | ||
| 1320 | 17.5.3 The Supplier shall investigate and fix application related defects in the System as reported by the Company within the Response Time and Resolution Time set out in Section 17.6.3 below. This includes any temporary corrections and bypass of defects until such time as standard corrections and/or updates of the System are available. The Supplier shall remove such temporary fixes after full resolution of the defect, at no additional cost to the Company. | ||
| 1321 | 17.5.4 The Supplier shall support the Company in recovering lost data, restoration and repair of damaged data and the correction of erroneous data to the extent commercially possible due to defects in the System. | ||
| 1322 | 17.5.5 Supplier shall update Documentation with changes made to the System during defect fixes. | ||
| 1323 | 17.5.6 For any new problem sequences and enhancements that are identified, Supplier shall: | ||
| 1324 | 17.5.6.1 Prepare, plan, conduct and deploy test scenarios, conditions and data for SIT; and | ||
| 1325 | 17.5.6.2 Prepare, plan, conduct and support deployment of test scenarios, conditions and data for UAT; and | ||
| 1326 | 17.5.6.3 Plan, conduct and support deployment of approved defect fixes to production. | ||
| 1327 | 17.5.7 All Incidents and Problems shall be classified in accordance with the following severity levels : | ||
| 1329 | 17.6 Performance Indicators for SLA compliance | ||
| 1330 | 17.6.1 The SLA compliance consists of: | ||
| 1331 | 17.6.1.1 Cybersecurity Incident Response time for each Severity Level. | ||
| 1332 | 17.6.1.2 Incidents and Problem Resolution time for each Severity Level. | ||
| 1333 | 17.6.1.3 System Availability | ||
| 1334 | 17.6.2 The Cybersecurity Incident Response Plan for each Severity Level is indicated as below: | ||
| 1335 | 17.6.3 The Response Time and Resolution Time for each Severity Level is indicated below : | ||
| 1337 | 17.6.4 The Resolution Time for replacement of hardware (if applicable) shall be within four (4) hours from the time the Company informs the Supplier of the faulty hardware. | There is no hardware to be supplied as part of the scope | |
| 1338 | 17.6.5 Regardless of whether the Supplier responds to Incident(s) on-site, the “Incident Resolution Time” shall begin upon acknowledgment of Incident(s) logged by Company via the telephone number/email/portal provided and shall end when the Incident (s) are resolved with a mutually agreeable workaround or the System is restored to a satisfactory working condition. | ||
| 1339 | 17.6.6 Regardless of whether the Supplier responds to Problem(s) on-site, the “Problem Resolution Time” shall begin upon acknowledgment of Problem(s) logged by Company via the telephone number/email/portal provided and shall end when the Problem(s) are resolved permanently. | The resolution time and response time will only be calculated for hours spent on actions to be taken by Armor | |
| 1340 | 17.7 Threat Hunting SLA Requirements | ||
| 1341 | 17.7.1 The Supplier shall commit to defined Service Level Agreements (SLAs) for all threat hunting activities to ensure timely and effective response to evolving threats. These SLAs cover ad-hoc requests from RWS, proactive intelligence-led hunts, and reporting obligations. | ||
| 1342 | 17.7.2 Acknowledgements of Requests | ||
| 1343 | 17.7.2.1 Supplier must acknowledge any ad-hoc threat hunting requests submitted by RWS within four (4) hours. | ||
| 1344 | 17.7.2.2 Acknowledgement must include assigned owner, expected timelines, and scope confirmation. | ||
| 1345 | 17.7.3 Indicator-Based Hunting (IoC Sweeps) | ||
| 1346 | 17.7.3.1 Supplier must complete indicator-of-compromise (IoC) sweeps across all relevant telemetry (endpoint, network, identity, SaaS, OT where applicable) according to the following tiered schedule: Critical IoCs must be completed within four (4) hours, and Standard IoCs must be completed within twenty-four (24) hours, as detailed in the Section 17.7 (Threat Hunting SLA Requirements). | ||
| 1347 | 17.7.3.2 IoCs include but not limited to hashes, domains, IPs, filenames, and registry keys. | ||
| 1348 | 17.7.4 Complex Hypothesis-Driven Hunting | ||
| 1349 | 17.7.4.1 Supplier shall complete hypothesis-driven hunting (e.g., suspected lateral movement, credential abuse, rare parent-child process anomalies, anomalous OAuth activity) within seventy-two (72) hours. | ||
| 1350 | 17.7.4.2 Supplier must document methods, datasets queried, and reasoning. | ||
| 1351 | 17.7.5 Proactive Intelligence-Led Hunting | ||
| 1352 | 17.7.5.1 Supplier shall automatically initiate hunts within twenty-four (24) hours of ingesting new threat intelligence (commercial, community, or RWS-specific). | ||
| 1353 | 17.7.5.2 Hunts must retroactively sweep at least the last 30-90 days of telemetry depending on data availability. | ||
| 1354 | 17.7.6 Hunting Reporting | ||
| 1355 | 17.7.6.1 Supplier shall deliver a hunt report within twenty-four (24) hours of hunt completion. | ||
| 1356 | 17.7.6.2 Reports must include scope, query details, dataset sources, hunt findings. Identified risks, and recommended follow-up actions. | ||
| 1357 | 17.7.7 Threat Hunting SLA Requirements | ||
| 1359 | 17.8 SLA Compensation | ||
| 1362 | 17.8.1 Incident, Problem and System Availability affected by the following scenarios will be excluded for the monthly SLA target measurement: | ||
| 1363 | 17.8.1.1 Scheduled downtime for maintenance, patching etc. | ||
| 1364 | 17.8.1.2 Company approved emergency maintenance | ||
| 1365 | 17.9 Failure to Meet SLA | ||
| 1366 | 17.9.1 Where the Supplier fails to meet the SLA, the Supplier will provide the SLA Compensation as set out in Section 17.8 above. | ||
| 1367 | 17.9.2 For any non-compliance to the SLA Indicator, the Supplier shall submit a report to the Company, stating reasons for missing the SLA and an action plan with mitigation steps to ensure the SLA is met in the following months. The plan is subject to mutual agreement between the Company and Supplier. | Armor cannot guarantee Microsoft platform SLOs - Performance observations will be reported but not guaranteed as SLO commitments. We can only commit to service SLAs | |
| 1368 | 17.10 System Availability | ||
| 1369 | 17.10.1 The “System Availability” is defined as: | ||
| 1371 | 17.10.2 The System shall cater for redundancies to achieve high availability and reliability utilising technologies such as failover clustering and load balancing. | ||
| 1372 | 17.10.3 The System shall leverage on two (2) data centres (a primary data centre and a secondary data centre) at different sites available within Company’s premises, to provide data centre failover mechanism in order to achieve high resiliency between the two (2) data centres in addition to the onsite high availability architecture. | ||
| 1373 | 17.10.4 The System shall achieve 99.9% availability per calendar month, excluding the scheduled downtime. | ||
| 1374 | 17.10.5 The System shall be available for seven (7) days a week, twenty-four (24) hours a day. | ||
| 1375 | 17.10.6 The System shall be available to users with no or minimum loss of System performance when the System is being backed-up, performing housekeeping or running any routine tasks. | ||
| 1376 | 17.11 System Reliability | ||
| 1377 | 17.11.1 The System shall be fully tested and quality assured before going live, so as to ensure maximum reliability (“System Reliability”). | ||
| 1378 | 17.11.2 The System shall be able to detect any forms of data integrity such as absence of data or corrupted / incorrect data during the sending or receiving of data. | ||
| 1379 | 17.11.3 The System shall be able to recover all data stored up to the last successfully completed transaction before a particular Incident occurs. | ||
| 1380 | 17.12 System Performance | ||
| 1381 | 17.12.1 The System response time during peak level operations shall be three (3) seconds or less for 80% and within five (5) seconds for 90% of the business transactions. Maximum response time shall not exceed fifteen (15) seconds except for agreed exclusions (“System Performance”). | Armor cannot guarantee Microsoft platform SLOs - Performance observations will be reported but not guaranteed | |
| 1382 | 17.12.2 Response time is defined as the time elapsed after depressing an ENTER key (or clicking on a button that submits the screen for processing) until a response is received back on the same screen. | Armor cannot guarantee Microsoft platform SLOs - Performance observations will be reported but not guaranteed | |
| 1383 | 17.12.3 The System shall be able to generate Static Standard report within fifteen (15) seconds or less from all the user locations within a local network 90% of the time. | Armor cannot guarantee Microsoft platform SLOs - Performance observations will be reported but not guaranteed | |
| 1384 | 17.12.4 The System shall return a Parameter-based report within 30 seconds or less. | Armor cannot guarantee Microsoft platform SLOs - Performance observations will be reported but not guaranteed | |
| 1385 | 17.13 Standard Operating Environment | ||
| 1386 | 17.13.1 The Supplier shall adhere to the following standard operating environment : | ||
| 1387 | 17.13.1.1 Platform | ||
| 1388 | 17.13.1.2 Operating System | ||
| 1389 | 17.13.1.3 Database | ||
| 1390 | 17.13.1.4 Browser | ||
| 1391 | 17.13.1.5 Common Services | ||
| 1392 | 17.13.1.6 Network Services | ||
| 1393 | 17.13.1.7 End User Device Platform | ||
| 1394 | 17.13.1.8 Others | ||
| 1395 | 17.14 Any ambiguity between technical SLOs and contractual SLAs shall be resolved in favour of the stricter obligations. | Armor cannot guarantee Microsoft platform SLOs - Performance observations will be reported but not guaranteed | |
| 1396 | 18. Security Requirements | ||
| 1397 | 18.1 The Supplier shall ensure that the System complies with the relevant laws, policies and directives set forth by the regulatory authorities. | ||
| 1398 | 18.2 Company’s Policies and Standards | ||
| 1399 | 18.2.1 The Supplier shall ensure that the System complies with the “IT Security Policy” and other relevant IT security policies and standards of the Company. | ||
| 1400 | 18.2.2 All of the Supplier’s personnel who need to access to the Company’s IT systems are required to read and acknowledge the “RWS IT End User Policy (For External Parties)”. The Supplier must adhere strictly to the policy. Any violation that wilfully degrades or violates the security of the Company’s IT infrastructure will be subject to financial penalties. | ||
| 1401 | 18.2.3 All of the Supplier’s personnel who require access to the Company’s casino properties, including systems and premises, shall obtain the relevant license as required by the regulatory authorities. | ||
| 1402 | 18.3 Information Handling | ||
| 1403 | 18.3.1 The Supplier shall be held accountable for the protection of all data and information under their due care to ensure that it is not used for other purposes unless the use has been authorised by the Company. The Supplier shall provide any information requested by the Company for the assessment of third party outsourcing. | ||
| 1404 | 18.3.2 The Supplier shall perform necessary security clearance, at a minimum a background check, for each of its personnel deployed for the Company. The Supplier shall sign non-disclosure agreement (“NDA”) with the Company. The NDA shall be applicable to all of Supplier’s personnel and sub-contractors’ personnel engaged by the Supplier to perform any task in the course of this LOA. | ||
| 1405 | 18.3.3 The Supplier shall have a system of control measures to protect confidential information against accidental or unlawful loss, as well as unauthorised access, disclosure, copying, use, or modification. The System shall include administrative, technical, physical and personnel control measures. The Supplier shall protect the data regardless of the format in which they are held. | ||
| 1406 | 18.3.4 The Supplier shall have the necessary processes and tools in place to ensure that deleted data or sensitive software is properly deleted and cannot be recovered by unauthorised personnel. Secure erasure of data and disposal of media shall meet industry media sanitisation standards such as National Institute of Standards and Technology (NIST) Special Publication 800-88 ‘Guidelines for Media Sanitisation’. | ||
| 1407 | 18.3.5 The Supplier shall provide a copy of Statement on Standards for Attestation Engagements (“SSAE”) 16 - Service Organization Control (“SOC”) 1 report to the Company on an annual basis. | ||
| 1408 | 18.4 Application System Security | ||
| 1409 | 18.4.1 If there are any code development or customisation to the System, the Supplier shall propose a software security framework to be used to formulate and implement a strategy for software security that is tailored to the specific risk that the Company faces. | ||
| 1410 | 18.4.2 The Supplier shall provide a detailed description of the proposed framework and activities involved, and how these will be implemented for the System. The framework should follow and meet industry recognisable framework such as Open Web Application Security Project (“OWASP”) Software Assurance Maturity Model (“SAMM”). | ||
| 1411 | 18.4.3 The Supplier shall scan the System for vulnerabilities and rectify them before deployment to the Company’s environment. | ||
| 1412 | 18.4.4 The System shall use fixed TCP/UDP ports. | ||
| 1413 | 18.4.5 Secure protocols such as SSH, SFTP shall be used. | ||
| 1414 | 18.4.6 The System shall store all account credentials as hashed or encrypted. | ||
| 1415 | 18.4.7 The Supplier shall not allow remote access or any other access to the System that circumvents the intended controls (e.g. via covert channel, backdoor, default support account) by its personnel unless the access is made known, properly justified and approved by the Company in advance. | ||
| 1416 | 18.4.8 Remote support of the System should not be allowed. If required, the Supplier shall indicate to the Company how remote support of the System is implemented and the measures taken for the protection of security and privacy of these sessions. | ||
| 1417 | 18.4.9 The System shall not perform, and shall not be able to be used to perform, any function that may change the security configuration, security file, or security program of the operating environment or platform in which the System runs. | ||
| 1418 | 18.4.10 Detailed system and network architecture and dataflow diagrams for the System shall be submitted for approval by the Company prior to implementation. | ||
| 1419 | 18.4.11 The Supplier must comply with the Company‘s change control process to ensure that all intended changes are properly reviewed, tested, and authorised before implementation. | ||
| 1420 | 18.4.12 The Supplier shall have sufficient control measures to ensure that no malicious codes such as virus, worm, Trojan-horse, or backdoor is introduced to the environment. | ||
| 1421 | 18.4.13 The UAT, production, and DR environment shall be hardened according to the Company’s IT hardening standards prior to UAT and commissioning of the System. These include, but are not limited to: | ||
| 1422 | 18.4.13.1 Changing of the default passwords and privilege IDs, | ||
| 1423 | 18.4.13.2 Removal of unused IDs, | ||
| 1424 | 18.4.13.3 Patching the System with the latest security updates, and | ||
| 1425 | 18.4.13.4 Reviewing all System default configurations for adequacy of security protection. | ||
| 1426 | 18.4.14 The System shall be implemented and deployed with sufficient security controls to protect it from unauthorised access and attack which may compromise the confidentiality, integrity and availability of data and information hosted by the System. | ||
| 1427 | 18.5 Application User Access Management | ||
| 1428 | 18.5.1 This is only applicable to the Company’s User (IT and business unit (“BU”)) Accounts | ||
| 1429 | 18.5.2 Authorisation and Access control shall be implemented at the: | ||
| 1430 | 18.5.2.1 Operating system level; and | ||
| 1431 | 18.5.2.2 Application level | ||
| 1432 | 18.5.3 The System shall support authentication via Microsoft Active Directory (“AD”) server for user identification (i.e. user will be prompted for login to the System). | ||
| 1433 | 18.5.4 The System shall be able to support automated user accounts provisioning by synchronising with the user accounts in the existing AD server. | ||
| 1434 | 18.5.5 Access to the System shall be designed based on the least privileged and segregation of duties principle. | ||
| 1435 | 18.5.6 Segregation of roles shall be clearly defined and documented for Privileged Users. Privileged Users refer to users such as ID Administrator, System Administrator of operating system, Security Administrator. | ||
| 1436 | 18.5.7 The System shall be able to support role-based user account configuration. Role assignment and role definition functions shall be segregated. | ||
| 1437 | 18.5.8 The user account management function shall allow user account creation, modification, disabling, deletion, and searching and displaying user account details. The role assignment function shall allow role creation, modification, deletion, searching and displaying role details. The role definition function shall allow adding and deleting functions to a role, and searching and displaying role details. | ||
| 1438 | 18.5.9 The System shall have the capability of interfacing with the Company’s Access Right Management System via a designated middleware in order to manage user administration, and access rights management, without any manual intervention; i.e. through interface(s). | ||
| 1439 | 18.5.10 The System shall have interface(s) which shall comply with the Company’s Interface Requirements, and shall have functionalities that include but are not limited to the following: | ||
| 1440 | 18.5.10.1 Retrieving a list of active users and their assigned role(s); | ||
| 1441 | 18.5.10.2 Adding a new user; | ||
| 1442 | 18.5.10.3 Updating an existing user (e.g. adding / removing role membership, or modifying user information); | ||
| 1443 | 18.5.10.4 Deleting a user; | ||
| 1444 | 18.5.10.5 Retrieving a list of roles including functions used by each role; | ||
| 1445 | 18.5.10.6 Retrieving a list of functions; | ||
| 1446 | 18.5.10.7 Retrieving access rights administration; and | ||
| 1447 | 18.5.10.8 Retrieving a list of transactions performed by privilege accounts. | ||
| 1448 | 18.5.11 The System shall be able to restrict security administration role to functions essential to perform security settings to the System. | ||
| 1449 | 18.5.12 The menu facility in the application showing the various functions shall be customisable by the user’s security profile. The options to which the users do not have access rights shall not be displayed. | ||
| 1450 | 18.5.13 Access to the application system via administrative accounts shall be secured by multi-factor authentication. | ||
| 1451 | 18.5.14 The Supplier shall provide a base set of role and functional matrix, for the Company to further tailor to its business needs. | ||
| 1452 | 18.5.15 The Supplier shall have a proper approval process and tracking mechanism for all access to the System and information to ensure proper usage and accountability. | ||
| 1453 | 18.5.16 The Supplier shall indicate if the System utilises a web based or client based architecture. Communication between the user and the System shall be secured during authentication and communication phases. | ||
| 1454 | 18.5.17 For web based architecture, the System design shall consider access control of URLs for different roles and business units. | ||
| 1455 | 18.5.18 The System shall be able to support inactive session auto logout. | ||
| 1456 | 18.6 Audit Trails and Report | ||
| 1457 | 18.6.1 This is only applicable to the Company’s User (IT and BU). | ||
| 1458 | 18.6.2 The System shall provide audit trails and reports for at least the following user activities: | ||
| 1459 | 18.6.2.1 User login/logout activities in the System; | ||
| 1460 | 18.6.2.2 Activities performed by privileged user and administrator accounts; | ||
| 1461 | 18.6.2.3 Failed user login; | ||
| 1462 | 18.6.2.4 Data updates activities (Data creation/modification/deletion); | ||
| 1463 | 18.6.2.5 Maintenance of confidential or sensitive master data; | ||
| 1464 | 18.6.2.6 Exceptional transactions such as repeated failed login attempts; | ||
| 1465 | 18.6.2.7 Account creation and deletion, role assignment and role(s) changes; and | ||
| 1466 | 18.6.2.8 Access or attempts to access the audit log file. | ||
| 1467 | 18.6.3 The System shall ensure that the audit trails are protected from unauthorised modification and deletion. | ||
| 1468 | 18.7 Database Security | ||
| 1469 | 18.7.1 The Supplier shall indicate how reports and data are protected at rest and in motion within the System and when interacting with other applications. | ||
| 1470 | 18.7.2 The System shall allow for encryption of confidential/sensitive fields in the database when required. | ||
| 1471 | 18.7.3 Data validation shall be performed by the data entry/maintenance programs. | ||
| 1472 | 18.7.4 The System shall be able to provide effective control reports for reconciling the System’s files and transactions. There should be adequate control mechanisms built in to validate acceptable interfaces and to flag interface problems. Examples include but are not limited to control reports, control totals and exception reporting. | ||
| 1473 | 18.7.5 All new interfaces created by the Supplier shall come complete with effective control mechanisms for reconciling the System’s files and transactions, validation of incoming data and to flag interface problems. Examples of control mechanisms include, but are not limited to, control reports, control totals and exception reporting. | ||
| 1474 | 18.7.6 The Supplier shall implement security measures to prevent system administrators or other privileged users from having direct access to the stored data. Stored data shall only be accessed via user interface. | ||
| 1475 | 18.8 Security Standard | ||
| 1476 | 18.8.1 The Supplier shall employ a reasonably strong industry cryptographic standard for required data and/or transmission encryption, such as Advanced Encryption Standard (AES) with key sizes of at least 256 bits, RSA Public Key Encryption with key sizes of at least 2048 bits, Secure Hash Algorithm (SHA-256). | ||
| 1477 | 18.8.2 The Supplier shall use reasonably strong industry cryptographic protocol in conjunction with the relevant cryptography standards, such as: | ||
| 1478 | 18.8.2.1 Transport Layer Security (TLS) version 1.2; | ||
| 1479 | 18.8.2.2 Use AES with GCM or CCM whenever possible; | ||
| 1480 | 18.8.2.3 Secure Shell (SSH) version 2; and | ||
| 1481 | 18.8.2.4 Password must not be stored in clear text. | ||
| 1482 | 18.8.3 Wireless devices and networks shall use WPA2 with AES for authentication and data encryption. | ||
| 1483 | 18.8.4 The Supplier shall avoid the use of unknown proprietary encryption algorithms. | ||
| 1484 | 18.8.5 The Supplier shall ensure that digital certificates that are deployed for the System shall conform to X.509 version 3. | ||
| 1485 | 18.8.6 The Supplier shall implement control measures that are needed to protect sensitive data, which includes but is not limited to system configuration, network architecture, system design, and any related data. The Supplier shall provide detailed description of the control measures. | ||
| 1486 | 18.9 Penetration Test (Post Commissioning Date) | ||
| 1487 | 18.9.1 RWS may perform validation or assurance testing (e.g., configuration review, control verification). No third-party penetration test is included within this Tender Scope. | ||
| 1488 | 19. Access Control and Audit Trail | ||
| 1489 | 19.1 The System shall support rights management capabilities to prevent unauthorised transactions and protect the System database from being tampered with. | ||
| 1490 | 19.2 The System shall support role-based access control and function to role mappings. | ||
| 1491 | 19.3 The System shall have audit logs which capture the actions of each user activity. | ||
| 1492 | 19.4 The System shall include history of all user interactions, edits and audit trail. These should minimally capture the action, date and time and the user that performed the change. | ||
| 1493 | 20. Integration Requirements | ||
| 1494 | 20.1 Active Directory | ||
| 1495 | 20.1.1 Supplier will conduct all integration works required for cross-system functionality, including setup with the Company’s AD single log in. This includes a mapping of the AD user schema to the System and access to enable AD log-in. | ||
| 1496 | 20.1.2 Supplier’s scope of work includes architecting and development of new authentication APIs to support AD log-in. Reconciliation of security standards, especially with oAuth, may be required and will be included as part of scope of work. | ||
| 1497 | 20.1.3 Supplier will also conduct testing with simulated users, along with basic penetration tests. | ||
| 1498 | 20.2 ID Administration System (“IDAS”) | ||
| 1499 | 20.2.1 The System shall integrate to IDAS through the standard web services interfaces in real time or via batch file for the purpose of: | ||
| 1500 | 20.2.1.1 User Profile creation / maintenance | ||
| 1501 | 20.2.1.2 User to Role list generation | ||
| 1502 | 20.2.1.3 Role to Function list generation | ||
| 1503 | 20.2.1.4 Active user list generation | ||
| 1504 | 20.2.1.5 Privilege account list generation | ||
| 1505 | 20.3 The System shall allow enough flexibility to integrate with more existing/new 3rd party system used by the Company. | ||
| 1506 | 21. DATA MIGRATION | ||
| 1507 | 21.1 The Supplier shall be responsible for migrating all existing configurations to the new System or Solution. This includes but is not limited to, rules, settings, dashboards, integrations with other tools and applications, alerts, and thresholds. | ||
| 1508 | 21.2 In the event the Supplier is unable to onboard all log sources within the stipulated timeframe defined in the project timeline, the Supplier shall redirect alerts from the existing system to the new System or Solution platform and ensure continuous security monitoring of the remaining log sources – at no additional cost to RWS. | ||
| 1509 | Such data migration shall be provided to the Company at no additional cost. | ||
| 1510 | 22. TECHNOLOGY stackS AND LIFECYCLE COMPLIANCE | ||
| 1511 | 22.1 Platform Requirements | ||
| 1512 | 22.1.1 The Supplier shall ensure that all components of the System are deployed on platforms that: | ||
| 1513 | 22.1.1.1 are supported by the Company’s IT department; | ||
| 1514 | 22.1.1.2 align with the Company’s current technology stacks in Section 22.6 of this Appendix B1; and | ||
| 1515 | 22.1.1.3 are explicitly approved in writing by the Company prior to deployment. | ||
| 1516 | 22.2 Operating System and Database Requirements | SWO to confirm | |
| 1517 | 22.2.1 The operating system and database used for the System must: | SWO to confirm | |
| 1518 | 22.2.1.1 remain within the Supplier’s mainstream support lifecycle for at least two (2) years from the Commissioning Date; and | SWO to confirm | |
| 1519 | 22.2.1.2 not be within two (2) years of their published EOS Date at the time of commissioning. | SWO to confirm | |
| 1520 | 22.2.2 For the purposes of this LOA, “EOS Date” means the date published by the original software manufacturer after which the product will no longer receive security updates or vendor support. | SWO to confirm | |
| 1521 | 22.3 Software Support Lifecycle Compliance | ||
| 1522 | 22.3.1 The Supplier shall ensure that all software developed, provided, or incorporated into the System — including, without limitation, all third-party and open-source components, remain within the active support lifecycle of the original manufacturer or maintainer for the duration of its use within the System. No component shall be deployed if the EOS Date has already elapsed by the Commissioning Date or will elapse shortly after the Commissioning Date. | SWO to confirm | |
| 1523 | 22.4 Ongoing Compliance Warranty | ||
| 1524 | 22.4.1 The Supplier expressly warrants that all platforms, operating systems, databases, and software components used in the System will remain compliant with Sections 22.1 to 22.3 for the Term of this LOA. | SWO to confirm | |
| 1525 | 22.4.2 If any component approaches or reaches EOS Date during the Term of this LOA, the Supplier shall, at its sole cost and without delay or service disruption, upgrade, replace, or reconfigure the affected component to restore compliance. | SWO to confirm | |
| 1526 | 22.5 Deviation from Standards | SWO to confirm | |
| 1527 | 22.5.1 Any deviation from the requirements set out in Sections 22.1 to 22.4 requires prior written consent from the Company, obtained through the Company’s formal architecture change control process. | SWO to confirm | |
| 1528 | 22.6 Technology Stacks | ||
| 1529 | 22.6.1 Standard Technology Stack | ||
| 1531 | 22.6.2 Network Technology stacks (applicable for infrastructure network related project only) | ||
| 1533 | 22.6.3 Application Technology stacks (applicable for custom-build applications) | ||
| 1535 | 23. MANPOWER DEPLOYED | ||
| 1536 | 23.1 The Supplier shall undertake that they will not employ any illegal foreign workers for the purpose of completing the LOA in contravention of the Immigration Act (Cap. 133) (and/or any modifications and amendments after the date of execution of the LOA) or any other relevant law. | ||
| 1537 | 23.2 In the event the Services to be performed requires entry into the RWS Casino, the Supplier shall undertake that all assigned or onsite staff meet the following requirements: | ||
| 1538 | 23.2.1 Be of the age of 21 years and above; | ||
| 1539 | 23.2.2 Shall not be on the casino’s exclusion list; | ||
| 1540 | 23.2.3 Shall not have past history of criminal offence; and | ||
| 1541 | 23.2.4 Follow the rules and regulations of the Company. | ||
| 1542 | 23.3 In addition, the Supplier shall procure that any assigned or onsite staff entering the RWS Casino without payment of entry levy: | ||
| 1543 | 23.3.1 Shall not take part in any gaming activities inside the casino; | ||
| 1544 | 23.3.2 Shall not loiter around or visit the casino floor without the Company’s approval; | ||
| 1545 | 23.3.3 Display their passes prominently without demand at all times; and | ||
| 1546 | 23.3.4 Be dressed and behave in a professional manner. | ||
| 1547 | 23.4 The Supplier shall be liable for and shall indemnify the Company against any damage, expense, liability, losses, claims and/or proceedings whatsoever arising out of the Supplier’s default in complying with the above undertakings. For purpose of this section, the Supplier shall provide a written undertakings in connection with the above within two (2) weeks of signing of this LOA. | ||
| 1548 | 24. FULFILMENT PARTNER | ||
| 1549 | 24.1 The Supplier wishes to appoint the following fulfilment partners for the Services (“Fulfilment Partners”): | ||
| 1550 | 24.1.1 Armor Defense Asia Pte. Ltd. (Business Registration Number: 202222526H | ||
| 1551 | 24.1.2 <INSERT NAME OF COMPANY> (Business Registration Number: XXXXXXXXXX) | ||
| 1552 | 24.1.3 <INSERT NAME OF COMPANY> (Business Registration Number: XXXXXXXXXX) | ||
| 1553 | 24.2 The Supplier shall procure that the Fulfilment Partners complies with all the terms and conditions of the LOA. | ||
| 1554 | 24.3 The Supplier shall procure that the Fulfilment Partners will not vary the prices or scope of the Services throughout the term of the LOA. | ||
| 1555 | 24.4 The Supplier agrees that the Fulfilment Partners shall be deemed an agent of the Supplier and the Supplier shall be liable for all acts and/or omissions of the Fulfilment Partners. | ||
| 1556 | 24.5 The Supplier agrees to indemnify and save harmless Company from and against all losses which the Company may suffer in connection with the acts and/or omissions of the Fulfilment Partners including any penalties imposed by the Casino Regulatory Authority for the Fulfilment Partners’ infringement of any rules and regulations. | ||
| 1557 | 24.6 If required by the Company, the Supplier shall procure that the Fulfilment Partners assist the Company with any investigation, inquiry and/or discussions in relation to the Services without any additional cost to the Company. | ||
| 1558 | 25. Change Management | ||
| 1559 | 25.1 Throughout the term of this LOA, the Supplier shall provide enhancements/changes to the System as and when required by the Company. The Company shall be entitled to raise Change Request (“CR”) for such services from time to time. | ||
| 1560 | Change Request and CR Proposals | ||
| 1561 | 25.2 The Supplier shall submit the CR Proposal(s) to the Company within the following timelines: | ||
| 1563 | 25.3 Supplier will create/add the CR to the log entry, make an assessment of the CR, then subsequently submit a detailed CR proposal (“CR Proposal”) to the Company with the following information: | ||
| 1564 | 25.3.1 Summary Description | ||
| 1565 | A high level summary of requested change. | ||
| 1566 | 25.3.2 Scope of work | ||
| 1567 | 25.3.2.1 Detailed write up on the scope for this proposed solution which includes but is not limited to the following areas: | ||
| 1568 | 25.3.2.1.1 Project Management | ||
| 1569 | 25.3.2.1.2 Requirement Gathering | ||
| 1570 | 25.3.2.1.3 Functional Design | ||
| 1571 | 25.3.2.1.4 Technical Design | ||
| 1572 | 25.3.2.1.5 Development | ||
| 1573 | 25.3.2.1.6 SIT | ||
| 1574 | 25.3.2.1.7 UAT | ||
| 1575 | 25.3.2.1.8 Deployment | ||
| 1576 | 25.3.2.2 Detailed write up on how all the proposed changes to the System will be processed/applied to the modules of software, hardware and the Documentation; | ||
| 1577 | 25.3.2.3 Impact analysis, handling of changes to the proposed System (including rollback procedures); and | ||
| 1578 | 25.3.2.4 Tests and acceptance of the changes to the System. | ||
| 1579 | 25.3.3 Schedule | ||
| 1580 | Project schedule for proposed solution. | ||
| 1581 | 25.3.4 Effort & Cost | ||
| 1582 | Estimation of the effort required, and cost | ||
| 1583 | 25.3.5 Documentation and Updates Required | ||
| 1584 | Summary of existing artifacts that require updates. | ||
| 1585 | 25.3.6 Impact to current Maintenance Services | ||
| 1586 | Details of changes to current maintenance services. | ||
| 1587 | 25.3.7 Risks & Mitigation | ||
| 1588 | Details of potential risks and mitigation. | ||
| 1589 | 25.3.8 Assumption | ||
| 1590 | Details of assumption made for proposed solution. | ||
| 1591 | 25.4 For the avoidance of doubt, the Supplier shall bear all costs related to the preparation and submission of the CR Proposal(s) and Work Order(s) to the Company. | ||
| 1592 | 25.5 At the Company’s request, and at no additional cost, the Supplier will present the CR Proposal to the Company for clearance. Subsequently, the Company will inform the Supplier on the status of approval of the CR Proposal. | ||
| 1593 | 25.6 For CR Proposal(s) approved by the Company in writing, the Supplier will prepare and submit a Work Order to the Company which reflects: | ||
| 1594 | 25.6.1 The detailed scope of work, and effort estimated in the approved CR Proposal; and | ||
| 1595 | 25.6.2 Cost shall be in accordance with the rates and payment schedule set out in Appendix B2. | ||
| 1596 | 25.7 After the Work Order has been mutually agreed to in writing by the Company and the Supplier, the Supplier shall carry out the Work Order accordingly. | ||
| 1597 | Additional terms for Work Order | ||
| 1598 | 25.8 Company shall control the prioritisation of approved Work Order(s). For any unforeseen or urgent circumstances, the Company reserves the right to re-prioritise the Work Order(s). | ||
| 1599 | 25.9 The implementation of a Work Order may be carried out on a one-time basis or in phases, to be specified in the Work Order, or otherwise approved by the Company in writing. The approval required from the Company shall include the agreed number of man-days effort for each Work Order. | ||
| 1600 | 25.10 All Work Order(s) shall be subjected to UAT in the UAT environment, unless otherwise agreed by the Company. The implementation of a Work Order cannot be carried out before the UAT is completed, unless UAT is waived by the Company. | ||
| 1601 | 25.11 The Supplier’s scope of work in relation to each Work Order shall include but is not limited to the following: | ||
| 1602 | 25.11.1 Design, develop, test and implement the changes to the System according to the requirements in the Work Order. | ||
| 1603 | 25.11.2 Design a series of test cases to verify the proper functioning of all functions according to the specified requirements, including System integration. | ||
| 1604 | 25.11.3 Submit a comprehensive UAT plan including the actual scope of testing, the acceptance criteria and schedule of testing within a mutually agreed schedule prior to the actual conduct of the test. | ||
| 1605 | 25.11.4 Set up of UAT test data, if required by the Company. | ||
| 1606 | 25.11.5 Provide, prepare and/or update relevant documentation to reflect changes made to the System. | ||
| 1607 | 25.11.6 Ensure that the Work Order is completed and implemented within the timeline as stated in the Work Order. | ||
| 1608 | 25.12 The Supplier shall ensure that each Work Order is successfully implemented according to agreed schedule and man-days. If the Supplier cannot meet the pre-agreed schedule/man-efforts, any additional costs incurred shall be borne by the Supplier. | ||
| 1609 | The Work Order is considered completed after the modified System has been accepted, cutover to live environment and all relevant updated Documentation submitted and approved by Company. | ||
| 1610 | 26. Payment Schedule | ||
| 1611 | Supplier will invoice the Company in accordance with the following payment schedule: | ||
| 1613 | 26.1 Licenses, subscriptions, and any related cloud-service entitlements shall be activated only upon written authorization from RWS, following ARB approval and readiness confirmation. No billing shall commence prior to such authorization. | ||
| 1614 | 26.2 Subscriptions fees (Component A of Detailed Price Breakdown (XDR) shall be payable on an annual basis, upon written authorization and activation from RWS. | ||
| 1615 | 26.3 Managed MXDR services (Component D of Detailed Price Breakdown (XDR) shall be invoiced on recurring basis annually. | ||
| 1616 | 26.4 All payments shall be made to the Supplier within thirty (30) days from the date of a valid and undisputed invoice, in accordance with RWS’s standard payment procedures. | ||
| 1617 | 26.5 The Supplier shall provide a detailed Schedule of Rates covering add-on components such as additional software licenses, optional modules, professional services, and related items for potential future procurement during the contract duration. | ||
| 1618 | 26.6 The rates shall remain valid throughout the Contract Period, including the optional extension years, unless otherwise mutually revised and approved by RWS. | ||
| 1619 | APPENDIX B3 | ||
| 1620 | KEY PERFORMANCE INDICATORS | ||
| 1621 | I. Platform Health & Detection Effectiveness | ||
| 1622 | (Linked to Appendix B1 – Technical Requirements) | ||
| 1624 | II. SOC Operations & Response Performance | ||
| 1625 | (Linked to Appendix B1 – Managed XDR / SOC Requirements) | ||
| 1627 | III. MXDR Service Delivery & Continuous Improvement | ||
| 1628 | (Linked to Appendix B2 – Services and Schedule) | ||
| 1632 | Functional Requirements: Endpoint Protection Platform (EPP) | ||
| 1633 | 1. CORE ANTIVIRUS & ANTI-MALWARE | ||
| 1634 | 1.1. The system must perform static and dynamic machine learning analysis on files and processes to detect and block known and unknown malware, including trojans, ransomware, spyware, and viruses. | ||
| 1635 | 1.2. The system must not rely solely on traditional signature-based detection as its primary method. | ||
| 1636 | 1.3. The system must provide real-time, on-access scanning of files upon execution, creation, and modification. | ||
| 1637 | 1.4. The system must provide on-demand scanning capabilities, allowing administrators to initiate full or quick scans on single or groups of endpoints. | ||
| 1638 | 1.5. Upon detection, the system must automatically quarantine malicious files, moving them to a secure, encrypted holding area and terminating associated processes. | ||
| 1639 | 1.6. The system must provide a clear audit log for every detection, including file path, hash, associated process, action taken, and timestamp. | ||
| 1640 | 2. Exploit Prevention | ||
| 1641 | 2.1. The system must include a dedicated module to prevent the exploitation of memory corruption vulnerabilities (e.g., buffer overflows, use-after-free errors). | ||
| 1642 | 2.2. The system must protect widely deployed applications, including but not limited to: | ||
| 1643 | 2.2.1. Microsoft Office Suite | ||
| 1644 | 2.2.2. Web browsers | ||
| 1645 | 2.2.3. PDF readers | ||
| 1646 | 2.2.4. Media players and Java runtimes | ||
| 1647 | 2.3. The system must detect and block common shellcode injection techniques such as process hollowing, atom bombing, and dynamic link library (DLL) sideloading. | ||
| 1648 | 3. Behavioural-Based Prevention (Indicators of Attack – IoAs) | ||
| 1649 | 3.1. The system must analyse process behaviour in real-time to identify and block malicious sequences of activity, regardless of file reputation. | ||
| 1650 | 3.2. The system must be capable of detecting and preventing the following techniques through behavioural analysis: | ||
| 1651 | 3.2.1. Fileless attacks using legitimate tools like PowerShell, Windows Management Instrumentation (WMI), and Windows Script Host (WSH). | ||
| 1652 | 3.2.2. Ransomware encryption behaviour by monitoring for rapid, sequential file modifications with specific extensions. | ||
| 1653 | 3.2.3. Credential access and dumping techniques, including LSASS memory access and security descriptor modification. | ||
| 1654 | 3.2.4. Lateral movement attempts using tools like WMIexec, PsExec, or Remote Desktop Protocol (RDP). | ||
| 1655 | 3.2.5. Persistence mechanisms, such as registry run key modifications, service creation, and scheduled task registration. | ||
| 1656 | 3.3. The system must allow administrators to create custom IOA rules to block environment-specific malicious behaviours. | ||
| 1657 | 4. Device Control | ||
| 1658 | 4.1. The system must provide granular policy management for removable media and peripheral devices. | ||
| 1659 | 4.2. Policies must allow for control based on device class, vendor ID, product ID, or serial number. | ||
| 1660 | 4.3. Control options must include: | ||
| 1661 | 4.3.1. Read-only access | ||
| 1662 | 4.3.2. Write-only access | ||
| 1663 | 4.3.3. Block-all access | ||
| 1664 | 4.3.4. Full read/write access | ||
| 1665 | 4.4. The system must provide logging of all device access attempts, including the device used, the host computer, the user, and the action taken. | ||
| 1666 | 5. Host-Based Firewall Management | ||
| 1667 | 5.1. The system must provide a host-based firewall for Windows and macOS endpoints. | ||
| 1668 | 5.2. The firewall must be centrally managed through the administration console, allowing for the creation and enforcement of firewall rules across endpoint groups. | ||
| 1669 | 5.3. Rule creation must be based on criteria such as: | ||
| 1670 | 5.3.1. Application path and hash | ||
| 1671 | 5.3.2. Direction of traffic (inbound/outbound) | ||
| 1672 | 5.3.3. IP address, port, and protocol | ||
| 1673 | 5.4. The system must include pre-configured rule sets for common operating system services and applications. | ||
| 1674 | 6. Centralized Management and Reporting | ||
| 1675 | 6.1. All prevention policies must be managed from a single, web-based console. | ||
| 1676 | 6.2. The console must allow for the creation of different policy sets for different groups of endpoints (e.g., servers, workstations, kiosks). | ||
| 1677 | 6.3. The system must provide real-time and historical reporting on: | ||
| 1678 | 6.3.1. Prevention events (blocks, quarantines) | ||
| 1679 | 6.3.2. Agent health and status | ||
| 1680 | 6.3.3. Overall endpoints security posture | ||
| 1681 | 6.4. The system must provide pre-built compliance reports for frameworks such as NIST and CIS Critical Security Controls. | ||
| 1682 | 7. Performance and System Impact | ||
| 1683 | 7.1. The agent must demonstrate a minimal and predictable impact on endpoint performance during independent testing. | ||
| 1684 | 7.2. The maximum acceptable CPU utilization during an on-access scan must not exceed 5% on a standard corporate endpoint. | ||
| 1685 | 7.3. The agent's memory footprint must not exceed 250 MB under normal operating conditions. | ||
| 1686 | 7.4. The agent must not cause a noticeable increase in system boot time or logon duration. | ||
| 1687 | 7.5. The system must provide administrators with granular controls to schedule resource-intensive activities (such as full scans) during off-peak hours. | ||
| 1688 | 7.6. The agent must enter a low-power state when an endpoint is running on battery power to conserve energy, unless overridden by policy. | ||
| 1689 | 8. Agent Deployment, Architecture & Operational Efficiency | ||
| 1690 | 8.1. The solution shall use a single agent for all supported endpoints, servers, workstations, virtual desktops or machines, and containers. | ||
| 1691 | 8.2. The solution shall provide a single installer package that supports all required operating systems and workload types. | ||
| 1692 | 8.3. The solution shall support streamlined, large-scale deployment without dependency sequencing. | ||
| 1693 | 8.4. The same agent shall provide full capability on endpoints, servers, workstations, virtual desktop or machines, and containers without requiring different versions or reduced functionality modes. | ||
| 1694 | 9. Resilience and Tamper Protection | ||
| 1695 | 9.1. The endpoint agent shall operate as a fully self-protecting security control with built-in anti-tampering that prevents unauthorized termination, suspension, unloading, or modification of its processes, drivers, services, and protection capabilities – even if an attacker obtains local administrator privileges or executes remote commands (e.g., via reverse shell, C2 payloads, or elevated scripting. | ||
| 1696 | 9.2. Any attempt to disable, uninstall, reconfigure, or stop protection must require explicit authorization through secure, auditable centralized administrative controls. Tampering shall not be possible through operating systems tools, registry edits, Group Policy changes, Powershell, service control commands, or command-line execution. | ||
| 1697 | 9.3. The solution must implement kernel-level protection and a hardened architecture that is not dependent on traditional OS user-mode services and cannot be neutralized by privilege escalation, service-kill attempts, Safe-Mode execution, or driver removal. | ||
| 1698 | 9.4. The agent shall support autonomous self-healing, automatically restoring any service, driver, binary, or component that is stopped, corrupted, modified, or replaced – without requiring manual intervention and regardless of network connectivity state. | ||
| 1699 | 9.5. Security controls, prevention policies, and telemetry collection must remain continuously active and enforceable even when the endpoint is: | ||
| 1700 | 9.5.1. Offline or disconnected from the network | ||
| 1701 | 9.5.2. Operating in Windows Safe Mode | ||
| 1702 | 9.5.3. Operating under an attacker-controlled session or credential context | ||
| 1703 | 9.6. The solution shall enforce cryptographic integrity for all agent components. Execution must be blocked if binaries are tampered, rolled back, injected, side-loaded, or replaced by unsigned or untrusted versions. | ||
| 1704 | 9.7. The agent must generate real-time, high-severity alerts on any attempts to modify, suspend, remove, bypass, or disable protections – including via reverse shell or automated programs. | ||
| 1705 | 9.8. The Supplier shall demonstrate or provide attestation that the solution: | ||
| 1706 | 9.8.1. Cannot be disabled via service termination or local administrative access | ||
| 1707 | 9.8.2. Maintains enforcement even under remote shell execution | ||
| 1708 | 9.8.3. Remains operational in Safe Mode | ||
| 1709 | 9.8.4. Recovers automatically when tampered with | ||
| 1710 | 9.8.5. Meets enterprise red-team and adversarial test standards | ||
| 1711 | 10. Policy Management and Configuration | ||
| 1712 | 10.1. The administration console must provide a role-based access control (RBAC) system to delegate administrative permissions. | ||
| 1713 | 10.2. The system must allow for policies to be applied dynamically based on endpoint tags, such as operating system, location, or network zone. | ||
| 1714 | 10.3. The console must provide a preview mode to simulate the impact of a policy before enforcement. | ||
| 1715 | 10.4. The system must maintain a version history of all policy changes, including who made the change and when. | ||
| 1716 | 10.5. The system must allow for the graceful rollback of a policy to a previous version if necessary. | ||
| 1717 | 11. Reporting and Forensics | ||
| 1718 | 11.1. The system must provide a dedicated dashboard for real-time visualization of prevention events across the environment. | ||
| 1719 | 11.2. Administrators must be able to create custom reports and schedule them for automatic generation and distribution. | ||
| 1720 | 11.3. For every blocked event, the system must provide a detailed forensic timeline, showing the process tree and file activities that led to the prevention action. | ||
| 1721 | 11.4. All report data must be exportable to common formats (PDF, CSV) for further analysis or archival purposes. | ||
| 1722 | 11.5. The system must provide API access to all report data for integration with external SIEM or analytics platforms. | ||
| 1723 | Functional Requirements: Endpoint Detection and Response (EDR) | ||
| 1724 | 1. Data Collection and Telemetry | ||
| 1725 | 1.1. The agent must continuously record a high-fidelity, chronological timeline of endpoint activity without relying on traditional logging systems (e.g., Windows Event Logs). | ||
| 1726 | 1.2. The recorded telemetry must, at a minimum, include the following data points for each event: | ||
| 1727 | 1.2.1. Process execution data, including process name, path, hash, command-line arguments, parent/child process relationships, user context, and integrity level. | ||
| 1728 | 1.2.2. File system activity, including file creation, read, write, move, deletion, and attribute changes, with full file paths and hashes. | ||
| 1729 | 1.2.3. Network connection data, including source and destination IP addresses, port numbers, protocol, domain names, and the process initiating the connection. | ||
| 1730 | 1.2.4. Registry modifications for both keys and values, including creation, deletion, and value changes. | ||
| 1731 | 1.2.5. Module (DLL) loading activity, including the source process and load address. | ||
| 1732 | 1.2.6. User logon and authentication events, including logon type and source IP address. | ||
| 1733 | 1.3. The system must retain this detailed telemetry data in a hot, searchable state for a minimum of 90 days for all endpoints. | ||
| 1734 | 1.4. The agent must cache telemetry data locally and resiliently transmit it to the cloud console upon re-establishing connectivity, ensuring no data loss during network outages. | ||
| 1735 | 2. Threat Detection and Alerting | ||
| 1736 | 2.1. The detection engine must correlate low-level telemetry events into high-fidelity security alerts based on behavioural patterns and Indicators of Attack (IOAs). | ||
| 1737 | 2.2. Every alert must be automatically mapped to the specific MITRE ATT&CK Framework tactic, technique (ID), and sub-technique (ID). | ||
| 1738 | 2.3. The system must assign a dynamic severity score (e.g., Critical, High, Medium, Low) to each alert based on the confidence level and the potential impact on RWS. | ||
| 1739 | 2.4. The system must provide a library of pre-tuned, out-of-the-box detection rules for common adversary TTPs, which are continuously updated by the vendor's threat intelligence team. | ||
| 1740 | 2.5. The system must allow security analysts to create custom detection rules using a powerful query language to detect environment-specific threats. | ||
| 1741 | 3. Threat Hunting and Investigation | ||
| 1742 | 3.1. The system must provide an advanced query language (e.g., based on SQL, KQL) that allows analysts to search interactively across all collected telemetry data from all endpoints. | ||
| 1743 | 3.2. Analysts must be able to save, schedule, and share their queries for continuous monitoring and operationalization into custom detections. | ||
| 1744 | 3.3. The system must provide a graphical investigation tool that visually maps the complete attack chain, automatically displaying the relationships between processes, files, network connections, and users involved in an incident. | ||
| 1745 | 3.4. Analysts must be able to pivot seamlessly from any alert, event, or entity within the console directly into the raw, detailed telemetry data for deeper context and analysis. | ||
| 1746 | 3.5. The investigation interface must provide a timeline view of all related activity, allowing analysts to step through the sequence of events before, during, and after an alert. | ||
| 1747 | 4. Response and Remediation | ||
| 1748 | 4.1. The system must provide remote response capabilities directly from the management console, allowing analysts to take immediate action on any endpoint without requiring a secondary remote access tool. | ||
| 1749 | 4.2. Response capabilities must include, at a minimum: | ||
| 1750 | 4.2.1. Remote shell access for live investigation and command execution. | ||
| 1751 | 4.2.2. The ability to kill running processes and terminate malicious activity. | ||
| 1752 | 4.2.3. The ability to delete or quarantine malicious files identified during an investigation. | ||
| 1753 | 4.2.4. The ability to isolate an endpoint from the network (either fully or selectively) while maintaining management connectivity to the agent. | ||
| 1754 | 4.2.5. The ability to upload and execute custom scripts or tools across a group of endpoints for large-scale remediation. | ||
| 1755 | 4.3. All response actions must be logged in an immutable audit trail, detailing who took the action, when, on which endpoint, and the outcome. | ||
| 1756 | 5. Integration and Automation | ||
| 1757 | 5.1. The system must provide a fully documented RESTful API that allows for bidirectional integration with external systems like SIEM, SOAR, and IT Service Management (ITSM) platforms. | ||
| 1758 | 5.2. The API must allow for the programmatic retrieval of alerts, endpoints, and investigation data. | ||
| 1759 | 5.3. The API must allow external systems to initiate response actions (e.g., isolate device, run scan) within the EDR platform. | ||
| 1760 | 5.4. The system must support the ingestion of external threat intelligence (e.g., IOCs in STIX/TAXII format) to automatically tag malicious activity and enhance detection. | ||
| 1761 | Functional Requirements: Extended Detection and Response (XDR) | ||
| 1762 | 1. Core Data Integration and Normalization | ||
| 1763 | 1.1. The platform must natively integrate with and ingest data from a wide range of security and IT products beyond the endpoint, without requiring custom parsing or complex configuration | ||
| 1764 | 1.2. The system shall provide pre-built and fully supported integrations for a broad range of data sources. These integrations must enable seamless ingestion and normalization of security-relevant data across the following categories: | ||
| 1765 | 1.2.1. Cloud Platform | ||
| 1766 | 1.2.2. Identity and Access Management | ||
| 1767 | 1.2.3. Email Solution | ||
| 1768 | 1.2.4. Network Infrastructure | ||
| 1769 | 1.2.5. Endpoint Detection and Response Tools | ||
| 1770 | 1.3. The platform shall normalize all ingested data into a unified, queryable schema, irrespective of the original format or source. This normalization must enable consistent search, correlation. | ||
| 1771 | 2. Cross-Domain Correlation and Analytics | ||
| 1772 | 2.1. The correlation engine must automatically analyse events across all integrated data sources (endpoint, cloud, identity, email, network) to identify multi-stage attacks that would be invisible to siloed tools. | ||
| 1773 | 2.2. The system must automatically stitch together related events from different domains to create a unified incident that tells the complete story of an attack. | ||
| 1774 | 2.3. The platform must use machine learning and behavioural analytics to establish a baseline of normal activity for users and systems and flag significant deviations that indicate potential compromise. | ||
| 1775 | 2.4. All correlated incidents must be automatically mapped to the MITRE ATT&CK framework, providing a clear understanding of the adversary's tactics and techniques across the entire kill chain. | ||
| 1776 | 3. Unified Incident Management and Investigation | ||
| 1777 | 3.1. The console must provide a single, unified view for incidents, regardless of which data sources were involved in the detection. | ||
| 1778 | 3.2. The investigation interface must provide a unified timeline that merges events from all domains (e.g., a timeline showing: malicious email received -> user credentials phished -> anomalous cloud logon -> malicious process execution on endpoint). | ||
| 1779 | 3.3. Analysts must be able to search and hunt across all normalized data using a single, powerful query language, without needing to learn source-specific syntax. | ||
| 1780 | 3.4. The system must allow an investigator to pivot from an identity alert directly to the affected endpoint data and cloud activity from that user, all within the same console. | ||
| 1781 | 4. Automated Response and Orchestration | ||
| 1782 | 4.1. The platform must provide pre-built, automated response playbooks that can act across different domains. For example: | ||
| 1783 | 4.1.1. Upon detecting a compromised identity, automatically force a user logoff and require a password reset. | ||
| 1784 | 4.1.2. Upon detecting a malicious cloud activity, automatically revoke a specific user's cloud session or permissions. | ||
| 1785 | 4.1.3. Upon detecting a network-based attack, automatically push a block rule to the firewall. | ||
| 1786 | 4.1.4. The system must include a built-in orchestration engine to execute these cross-domain response actions without requiring a separate SOAR product for basic use cases. | ||
| 1787 | 4.2. All automated actions must be logged in a central audit trail with details on the triggering event, the action taken, and the result. | ||
| 1788 | 5. Open API and Ecosystem | ||
| 1789 | 5.1. The platform must provide access to all core functions such as data ingestion, alert retrieval, incident management, and response actions via a well-documented RESTful API. | ||
| 1790 | 5.2. The API must use modern authentication and authorization standards (e.g., OAuth 2.0). | ||
| 1791 | 5.3. The API must support standardized data formats like JSON and must be capable of sending and receiving alerts in common schemas (e.g., CEF, OCSF). | ||
| 1792 | 5.4. The vendor must provide and maintain a library of pre-built API integrations for popular SIEM, SOAR, and IT Service Management platforms. | ||
| 1793 | Functional Requirements: Managed Extended Detection and Response (MXDR) | ||
| 1794 | 1. Service Foundation | ||
| 1795 | 1.1. The MXDR must deliver a 24/7/365 managed service, where the MXDR’s Security Operations Centre (SOC) assumes primary responsibility for monitoring, detection, validation, and initial response. | ||
| 1796 | 1.2. The MXDR must furnish a detailed RACI matrix (Responsible, Accountable, Consulted, Informed) that explicitly defines the division of responsibilities between the MXDR and RWS for all phases of security operations (Preparation, Detection, Analysis, Containment, Eradication, Recovery, Post-Incident Review). | ||
| 1797 | 1.3. Personnel and Expertise | ||
| 1798 | 1.3.1. All SOC analysts must hold advanced industry certifications (e.g., GCIH, GCFA, GNFA, GCFE, OSCP, CISSP) or equivalent qualifications for their role, with proof available for audit. | ||
| 1799 | 1.3.2. The MXDR must implement a mandatory continuous training program for all analysts, with a minimum of 40 hours annually dedicated to training on emerging threats, new attack techniques, and new platform features. | ||
| 1800 | 1.3.3. The MXDR must maintain dedicated teams for Tier 1 (Triage), Tier 2 (Analysis/Hunting), and Tier 3 (Incident Response/Threat Intelligence) functions, with clear escalation paths. | ||
| 1801 | 1.3.4. A dedicated Technical Account Manager (TAM) must be assigned, possessing a deep understanding of RWS’s environment, industry-specific threats, and business objectives. The TAM must be available for scheduled strategic reviews and urgent escalations. | ||
| 1802 | 2. Platform and Data Integration | ||
| 1803 | 2.1. Native Sensor Integration | ||
| 1804 | 2.1.1. The MXDR’s platform must include native, multi-tenant sensors/agents for endpoints (EDR), cloud workloads (CWPP), and identity providers, providing deep visibility and response capabilities without third-party dependencies. | ||
| 1805 | 2.1.2. The platform must support ingestion and normalization of data from a broad range of third-party sources, including but not limited to: | ||
| 1806 | 2.1.2.1. Network Infrastructure: Logs from firewalls, proxies, network flow data, DNS activity, and network detection and response systems. | ||
| 1807 | 2.1.2.2. Cloud Environments: Audit and activity logs, configuration monitoring data, and security posture information from major cloud service providers. | ||
| 1808 | 2.1.2.3. Email Security Systems: Threat detection and filtering logs from enterprise email protection platforms | ||
| 1809 | 2.1.2.4. Identity and Access Management System: Authentication events, audit logs, and directory service activity. | ||
| 1810 | 2.1.2.5. Application Sources: Logs from web servers, databases, and commonly used software-as-a-service(SaaS) applications. | ||
| 1811 | 2.2. Data Management and Analytics | ||
| 1812 | 2.2.1. The platform must perform real-time correlation across all integrated data sources to link related, low-fidelity events into high-fidelity incidents. | ||
| 1813 | 2.2.2. All data used for detection and investigation must be retained for a minimum of 90 days, with 365 days of hot storage available as an option. | ||
| 1814 | 2.2.3. The platform must automatically map detected activities to the MITRE ATT&CK framework (including Technique and Sub-Technique IDs) for consistent context and reporting. | ||
| 1815 | 3. Threat Detection and Analysis | ||
| 1816 | 3.1. Monitor and Triage | ||
| 1817 | 3.1.1. The MXDR must monitor and perform initial triage on 100% of alerts generated from all integrated data sources. | ||
| 1818 | 3.1.2. The MXDR must utilize a combination of proprietary and open-source threat intelligence feeds, updated in real-time, to enrich and contextualize all investigated alerts. | ||
| 1819 | 3.2. Proactive Threat Hunting | ||
| 1820 | 3.2.1. The MXDR must conduct continuous, hypothesis-driven threat hunting across RWS’s normalized data, not solely in response to alerts. | ||
| 1821 | 3.2.2. Hunting must be based on three pillars: | ||
| 1822 | 3.2.2.1. Intel-Driven: Hunting for IOCs and TTPs associated with current threat actors targeting the customer's industry. | ||
| 1823 | 3.2.2.2. Analytics-Driven: Searching for statistical anomalies and deviations from established baselines. | ||
| 1824 | 3.2.2.3. Suspicion-Driven: Investigating vague or weak signals that may indicate a sophisticated attacker. | ||
| 1825 | 3.2.3. All hunting activities, regardless of findings, must be documented and made available to RWS upon request. | ||
| 1826 | 3.3. Incident Analysis and Validation | ||
| 1827 | 3.3.1. Every validated incident must include a full kill-chain analysis, meticulously mapped to the MITRE ATT&CK framework. | ||
| 1828 | 3.3.2. The MXDR’s analysis must determine the scope of compromise, including all impacted endpoints, user accounts, cloud assets, and data sets. | ||
| 1829 | 3.3.3. The MXDR must deliver a confidence level (e.g., Critical, High, Medium, Low) for each incident, justifying the assessment with evidence. | ||
| 1830 | 4. Response and Remediation | ||
| 1831 | 4.1. Pre-Approved Playbook | ||
| 1832 | 4.1.1. The MXDR must work with RWS during onboarding to develop and document a detailed, multi-layered response playbook. | ||
| 1833 | 4.1.2. The playbook must define specific, pre-approved actions for common scenarios (e.g., ransomware, credential compromise, data exfiltration). | ||
| 1834 | 4.1.3. Actions must be granular, specifying exact commands, tools, and sequences to be used for containment. | ||
| 1835 | 4.2. Response Execution | ||
| 1836 | 4.2.1. For actions within the pre-approved playbook, the MXDR must execute containment measures immediately upon incident validation without requiring additional RWS sign-off. | ||
| 1837 | 4.2.2. The MXDR must maintain a 24/7 hotline and dedicated secure messaging channel (e.g., Teams) for immediate communication regarding any actions outside the playbook or for major incident declaration. | ||
| 1838 | 4.3. Post-Incident Activities | ||
| 1839 | 4.3.1. For every validated incident, the MXDR must deliver a comprehensive Incident Report within 24 hours of containment. | ||
| 1840 | 4.3.2. The MXDR must facilitate a post-incident review meeting for all high-severity incidents to discuss lessons learned and recommend control enhancements. | ||
| 1841 | 4.3.3. The MXDR must supply all relevant Indicators of Compromise (IOCs) and custom detection rules (YARA, SIGMA, etc.) derived from the incident. | ||
| 1842 | 5. Security, Compliance and Reporting | ||
| 1843 | 5.1. Security of the Service | ||
| 1844 | 5.1.1. Certification requirements for the Partner / System Integrator (Day1) and the MXDR Provider (Day2) shall be as defined in the Certification Requirements under Section 9. | ||
| 1845 | 5.1.2. All analyst access to RWS data and systems must be role-based, time-bound, logged, and monitored. Full audit trails of analyst actions must be immutable. | ||
| 1846 | 5.2. Reporting and Performance Management | ||
| 1847 | 5.2.1. The MXDR must deliver a real-time dashboard accessible to RWS showing key service metrics: MTTD, MTTR, incidents by severity, and SLA compliance. | ||
| 1848 | 5.2.2. A monthly executive report must detail threat trends, security posture score, top incidents, hunter findings, and recommendations. | ||
| 1849 | 5.2.3. Quarterly Business Reviews (QBRs) must be conducted with the RWS’s IT Security Team to review strategic alignment and service performance. | ||
| 1850 | 6. Onboarding, Offboarding, & Knowledge Transfer | ||
| 1851 | 6.1. Structured Onboarding Process | ||
| 1852 | 6.1.1. The MXDR must deliver a documented, phased onboarding plan with clear milestones, timelines, and designated resources from both parties. | ||
| 1853 | 6.1.2. The plan must include "Day 0 – Day 2" coverage commitment for the first critical data sources (e.g., endpoints, identity) while other sources are integrated. | ||
| 1854 | 6.1.3. The MXDR must assist in the deployment and configuration of any required sensors/agents, ensuring optimal performance and coverage. | ||
| 1855 | 6.2. Knowledge Transfer and Training | ||
| 1856 | 6.2.1. The MXDR must conduct formal training sessions for RWS’s IT Security Team on how to use the RWS-facing portal, interpret reports, and respond to MXDR communications. | ||
| 1857 | 6.2.2. The MXDR must deliver complete documentation of all deployed technologies, integration methods, and standard operating procedures (SOPs) used by the SOC for the RWS’s environment. | ||
| 1858 | 6.3. Secure Offboarding & Data Handling | ||
| 1859 | 6.3.1. Upon contract termination, the MXDR must permanently purge or return all RWS-specific data in accordance with a pre-defined data destruction policy. | ||
| 1860 | 6.3.2. The MXDR must assist in the orderly transition of services, including providing final reports and exporting any RWS-owned data (e.g., custom detection rules, historical incident data) in an open, non-proprietary format. | ||
| 1861 | 7. Technology & Platform Flexibility | ||
| 1862 | 7.1. Open Integration & API Access | ||
| 1863 | 7.1.1. The MXDR must offer full, well-documented API access to all platform functionalities, including alert ingestion, incident retrieval, and response actions, to enable integration with RWS’s existing SOAR or ticketing systems. | ||
| 1864 | 7.1.2. The platform must support common open standards (e.g., Open Cybersecurity Schema Framework (OCSF)) for data normalization to reduce integration complexity and cost. | ||
| 1865 | 7.1.3. Customization & Tuning | ||
| 1866 | 7.1.3.1. The MXDR must allow for the creation and tuning of custom detection rules to address RWS-specific applications, unique IT assets, or novel attack patterns observed in the environment. | ||
| 1867 | 7.1.3.2. The MXDR must work with RWS to establish RWS-specific baselines and allow-lists (e.g., for software, network traffic) to reduce false positives and focus on relevant threats. | ||
| 1868 | 7.1.4. Vendor Agnosticism and Flexibility | ||
| 1869 | 7.1.4.1. The service should be delivered effectively even if the customer chooses to retain but not limited to its existing endpoint (EDR) or network (NDR) security vendors, without being forced to "rip and replace" to use the MXDR’s proprietary tools. | ||
| 1870 | 7.1.4.2. The MXDR must demonstrate robust integrations with at least two leading vendors in each security control category | ||
| 1871 | 8. Strategic & Proactive Services | ||
| 1872 | 8.1. Vulnerability and Exposure Management | ||
| 1873 | 8.1.1. The service must include contextual vulnerability prioritization, correlating known software vulnerabilities (CVEs) with active threat intelligence and RWS specific exposure to highlight which vulnerabilities pose an immediate threat and must be patched first. | ||
| 1874 | 8.1.2. · The MXDR must identify and alert on security misconfigurations across endpoints, cloud environments, and identity providers that create material risk. | ||
| 1875 | 8.1.3. Threat Intelligence Program | ||
| 1876 | 8.1.3.1. Beyond incident response, the MXDR must deliver periodic security posture assessments that grade RWS’s security maturity across key domains (e.g., identity security, endpoint hardening, cloud configuration). | ||
| 1877 | 8.1.3.2. The assessment must include a prioritized list of actionable recommendations, tools, and policies to improve the security posture and reduce the overall attack surface. | ||
| 1878 | 9. Certification Requirements | ||
| 1879 | 9.1. Partner / System Integrator (Day-1) | ||
| 1880 | The appointed Partner / System Integrator responsible for solution deployment, onboarding, configuration, and implementation activities must hold a valid ISO/IEC 27001 Information Security Management System (ISMS) certification. | ||
| 1881 | The certification shall be current, valid, and supported by full audit documentation. | ||
| 1882 | 9.2. MXDR Provider (Day-2) | ||
| 1883 | The appointed MXDR Provider responsible for 24x7x365 managed detection and response services must meet the following requirements: | ||
| 1884 | · Hold a valid SOC 2 Type II certification or ISO/IEC 27001 certification and | ||
| 1885 | · Hold a valid Cybersecurity Service Provider Registration and Operations (CSRO) license | ||
| 1886 | All certifications must remain valid and enforceable throughout the contract duration, including any extension periods. | ||
| 1887 | 9.3. Technology and Solution Platform | ||
| 1888 | The XDR technology platform used to deliver detection, telemetry, ingestion, analytics, correlation, investigation, and response services – regardless of hosting models (SaaS, cloud, multi-tenant) – shall maintain: | ||
| 1889 | · SOC 2 Type II certification | ||
| 1890 | · ISO/IEC 27001 certification | ||
| 1891 | Where the MXDR services are delivered partially or wholly through Technology Provider platform, the Technology Provider must additionally hold a valid and appropriate CSRO license. | ||
| 1892 | 9.4. Certification Evidence Requirements | ||
| 1893 | All parties covered under these certification requirements (Day-1 - Partner/SI, Day-2 - MXDR Provider and Technology Provider) shall: | ||
| 1894 | · Provide complete and valid certification documents, including most recent audit reports. | ||
| 1895 | · Furnish such documents to RWS upon request for verification. | ||
| 1896 | · Maintain valid certifications for the entire contract period, including all renewals and extensions. | ||
| 1897 | · Immediately notify RWS in writing of any suspension, expiry, revocation, or lapse in certification status. |