AERC/PROC/RFP/COM/5502/2020-2021/012

1

AFRICA ECONOMIC RESEARCH CONSORTIUM (AERC)

AERC REQUEST FOR PROPOSAL (RFP):

Security Orchestration, Automation and Response (Soar) Solution for AERC Network

TERMS OF REFERENCE (TOR)

1. Background Cyber risks have become strategic imperatives due to their high negative impact to organizations globally. In response AERC is focusing on building operational resilience beyond preventive security controls. Part of this strategy includes the acquisition and implementation of an integrated Security Orchestration, Automation, and Response (SOAR).

This will provide integrated end to end cover of the IT infrastructure and related services. The system will autonomously synchronize controls to enforce policies and coordinate automated responses to threats detected across the network in a bid to ensure resilient operations.

2. Objectives The objective of this ToR is to acquire, implement and maintain a SOAR solution that will integrate cybersecurity controls towards autonomous security operations in defining, prioritizing and driving incidence analysis and standardized response. This solution will provide comprehensive visibility, monitoring, threat intelligence and automated incidence response in a bid to improve AERC’s risk profile. Specific objectives are outlined below:

i. Integrate and correlate security data and threat intelligence sources ii. Reduce security incidence detection, analysis and response time.

iii. Reduce reliance on manual security administration and lower related costs iv. Integrate with IT operations tools -- asset databases, helpdesk and configuration

management 3. Scope of work Securing AERC's from cyberattacks is critical in enabling the organization’s strategy. We are not only seeking a vendor to supply us with a solution but a partner to help realize the intended benefits through a sound implementation strategy and proven organizational adoption approach Based on this, the scope includes the following:

AERC/PROC/RFP/COM/5502/2020-2021/012

2

1. Supply, install, configure and maintain the SOAR solution that should meet the functional and technical requirements as specified in this RFP (see table at Annex 1- Functional requirements)

2. Provide SOAR Solution with core capabilities of:

• Real-time global overview of enterprise threat level • Incident Management & Response • Threat Hunting, Intelligence and Advisory Service • Traffic analysis/Inspection • Content inspection and filtering • Intelligently clusters anomalies • Concise summary of overall behavior for device and external IPs • Machine learning • Autonomous response

3. Develop and propose an implementation methodology containing a roadmap/schedule

for monitoring set targets and risks during the SOAR solution implementation (installation through deployment).

4. Deliver training services on the SOAR solution including EC- Councils SOC Analyst and Offensive Security’s OSCP, Pen testing certification credentials for two members of the AERC IT team

5. Deliver documentation of the solution from the installation, customization to deployment.

6. Provide support both remote and onsite for resolution of major technical problems 7. Asist in the development of appropriate security incidence response procedures in

alignment with related policies. 8. Provide maintenance of the solution i.e. Software version upgrade and hardware

replacement. Detailed breakdown of products/services required:

Products/Services Details 1. Supply of Software

with 1 year onsite comprehensive warranty

▪ Supply of license to implement SOAR with one-year warranty.

Refer to Annexure II 2. Project Services

Implementation ▪ Conducting 5 days Business Requirement Mapping ▪ Preparation of architecture design, documentation,

and project plan for implementation. ▪ Installation & Configuration of the supplied software

associated Software and System Integration.

AERC/PROC/RFP/COM/5502/2020-2021/012

3

▪ Development of appropriate security incidence response procedures in alignment with related policies.

9. Training on the SOAR solution administration including EC- Council’s SOC Analyst and Offensive Security’s OSCP, Pen testing certification credentials for two members of the AERC IT team

▪ Handing over of final configuration document. Refer to Annexure III for details.

3. Services – Support (AMC) ▪ Support from OEM during AMC on offered solution

for 1st, 2nd, 3rd Year. ▪ Software Subscription, Updates & Upgrades during

AMC support on offered solution for 1st,2nd, 3rd, Year.

4. TOR Outputs – Deliverables At the end of the implementation, the vendor should provide a comprehensive report with a detail of completed implementation work. The report will consist among others, the following:

i. SOAR solution that is fully implemented, well integrated, fine-tuned, and customized to AERC’s needs.

ii. Demo of the working solution to management and technical staff of AERC after completion of the implementation review and feedback.

iii. An executive summary report for management of the SOAR solution implemented iv. Two AERC IT staffers fully trained on administration of the SOC solution and one

trained and certified in EC-Council’s SOC Analyst credential and one on Offensive Security’s OSCP Pen Tester credential.

AERC/PROC/RFP/COM/5502/2020-2021/012

4

Annexure 1

Functional requirements for SOAR Solution Instructions: Please identify and describe the necessary compliance of your proposed solution to the features specified in the table below: Compliance Level Description

1: Fully Supported The function is supported as a standard/ configurable feature

within the package 2: Partially Supported The desired feature is partially supported

3: No Support The feature is not within scope of the provided Solution

In each requirement indicate the level of support using the table above by entering 1, 2 or 3 in the vendor support box.

AERC/PROC/RFP/COM/5502/2020-2021/012

5

Annexure‐II

Technical Specification for SOAR License, Windows Agents and Indicators of Compromise Modules

Technical Specification for SOAR

Sr. No#

Evaluation Criteria Compliance (1, 2 or 3)

Comments

1 General

1.1

a. The proposed product should be able to handle minimum 500 EPS & should be seamlessly scalable to process up to 1,000 EPS.

b. Solution should be able to integrate with minimum 100 no of devices with scalability up to 300.

1.2

The proposed product should be able to provide 365 days online data, 2 years offline and then backed up to 6 years storage.

1.3

The proposed product should take care of Event collection, flow collection, event processing, flow processing, correlation, analysis and reporting.

1.4 The Solution should be software/appliance based & deployable on a VM environment

1.5 The Solution should support extensive log file integrity checks.

2 Log Collection and Management

2.1

The system shall be able to capture all details in raw log, events and alerts and normalize them into a standard format for easy comprehension.

2.2 The solution should provide time based, criticality-based store and forward feature at each log collection point

2.3 The solution should prevent tampering of any type of logs and log any attempts to tamper logs

AERC/PROC/RFP/COM/5502/2020-2021/012

6

2.4 The solution should not drop any events once the EPS limit is exceeded

2.5 The solution should be able to conduct agent less collection of logs except for those which cannot publish native audit logs

2.6

The data archival should be configured to store information in tamper proof format and should comply with all the relevant regulations.

2.7

Should support the following log collection protocols: ( SNMP, WMI,VM SDK, OPSEC, JDBC, Telnet, SSH JMX), Windows Event Logging Protocol, Netflow at a minimum

2.8 It should be possible to store the event data in its original format in the central log storage

2.9

It should be feasible to extract raw logs from the SOAR and transfer to other systems as and when required.

2.10

All logs should be Authenticated (time‐stamped) encrypted and compressed before transmission

2.11

Traceability of logs shall be maintained from the date of generation to the date of purging.

2.12

The logger solution should be deployable on VM with EPS processing capacity of minimum 500 EPS. It should be seamlessly scalable to process up to 1,000 EPS without disturbing the existing setup.

3 Correlation

3.1

The solution should have the ability to correlate all the fields in a log

3.2 The solution should allow a wizard based interface for rule creation. The solution should support logical operations and nested rules for creation of complex rules

3.3

The central correlation engine database should be updated with real time security intelligence updates (IoC) from OEM

3.4

Solution should be able to perform the following correlations (but not limited to): Rule based, Vulnerability based, Statistical based, Historical based, Behavioral based etc.

AERC/PROC/RFP/COM/5502/2020-2021/012

7

3.5

SOAR must allow the creation of an unlimited number of new correlation rules

3.6

Ability to gather information on real time threats and zero day attacks issued by anti‐virus and IPS vendors and audit logs and add this information as intelligence feed in to the SOAR solution via patches or live feeds

4 Dashboard and Reporting

4.1

The proposed solution should provide the dashboard and Reports for viewing application vulnerabilities, and it should provide the aggregated, correlated information from all applications in the enterprises like Application Attack types and Top Apps Attacked etc.

4.2

The Tier I and II storage should have the capability to authenticate logs on the basis of time, integrity and Origin

4.3

The system should permit setting up geographical maps/images on real time dashboards to identify impacted areas and sources of alerts. Such geographical maps/images should be available to both console & web users.

4.4 The system should identify the originating system and user details while capturing event data.

4.5 The system should display all real time events. The solution should have drill down functionality to view individual events from the dashboard

4.6

The proposed solution should have the capability to encrypt/hash the logs in storage

4.7

The solution should offer a means of escalating alerts between various users of the solution, such that if alerts are not acknowledged in a predetermined timeframe, that alert is escalated to ensure it is investigated.

4.8 Capability to report on quantitative performance gain and resource savings. Key performance metrics that should be available on the platform include:

• Mean time to resolve (MTTR) • Average time saved per playbook run • Mean dwell time (MDT), which is defined

AERC/PROC/RFP/COM/5502/2020-2021/012

8

here as the period of time between a compromise (by a threat actor) and taking an appropriate response

• Performance against service level agreements (SLAs)

• Alerts closed through automation (per hour, day, week, month, or other time window

• User activity reports • Configuration change reports • Incident tracking report • Attack source reports

4.9 The solution should come with built‐in functionality for archiving data.

4.10

The solution should be able to store both normalized and RAW logs

4.11

The solution should allow users to initiate and track alert related mitigation action items. The portal should allow reports to be generated on pending mitigation activities

4.12

The solution should allow for qualification of security events and incidents for reporting purpose. The solution should be able to generate periodic reports (weekly, monthly basis) for such qualified security events/ incidents.

4.13

The solution should allow creating and saving of ad hoc log queries on archived and retained logs. These queries should be able to use standard syntax such as wildcards and regular expressions.

4.14

The solution should allow applying filters and sorting to query results.

4.15

The event should reach the SOC monitoring team within 30 seconds of the log being captured.

4.16

The dashboard should show the status of all the tools deployed as part of the SOC, including availability, bandwidth consumed, system resources consumed.

4.17

The dashboard should be in the form of a unified portal that can show correlated alerts/ events from multiple disparate sources such as security devices, network devices, enterprise management systems, servers, applications, databases, etc.

AERC/PROC/RFP/COM/5502/2020-2021/012

9

4.18

The Dashboard design for the solution should be editable on an ad hoc basis as per the individual user need

4.19

System should have capacity to maintain the logs for 1 year ONLINE and should have option to write to secondary storage systems for archiving.

4.20

There should be a mechanism to send alerts via E‐mail, SMS etc. whenever any incident occur based on the set threshold, conditions etc.

5 Event and Incident Management

5.1

Dashboard views should be customizable as per user rights and access to individual components of the application.

5.2

Dashboard should support reporting for consolidated relevant compliance for ISO 27001 regulatory requirements

5.3

Dashboard should support export of data to multiple formats including CSV, PDF formats

5.4

Dashboard should support different views relevant for different stake holders including top management, operations team, Information Security Department

5.5 Dashboard should display asset list and capture details including name, location, owner, value, business unit, IP address, platform details

5.6

Dashboard should capture the security status of assets and highlight risk level for each asset.

5.7

Any failures of the event collection infrastructure must be detected and operations personnel must be notified as per SLA. The device Health monitoring must include the ability to validate that original event sources are still sending events

5.8 Administrators should be able to view correlated events, real‐time raw logs and historical events through the dashboard.

6 Integration

AERC/PROC/RFP/COM/5502/2020-2021/012

10

6.1

The system should have out of the box rules for listed IDS/IPS, firewalls routers, switches, VPN devices, antivirus, operating systems, asset databases, helpdesk and configuration management and standard applications etc.

6.2

Should be able to integrate with physical access control systems.

6.3 Integrate with existing helpdesk/ incident management tools

6.4 Must be able to integrate with vulnerability management tool

6.5

SOAR solution must integrate with 3rd party SOC ticketing system for case management & escalation

7 Scalability

7.1

The system should receive feeds from a threat intelligence repository maintained by the vendor which consists of inputs from various threat sources and security devices across the globe.

7.2

The solution should be scalable as per data center roadmap for expansion

7.3

Solution should support integration with big data systems

8. Orchestration

8.1 The orchestrator should be able to ingest security data from any data source and in any format. It should be able to receive data that is pushed to the platform and it must have the ability to poll data sources and pull data into the platform

8.2 Users should be able to select the automation sets of standard SOP’s (playbooks) that are applied to a data source.

8.3 Effectively balance machine-based automation with necessary human supervision. There are three common scenarios where an analyst is required: when approval by an asset owner is needed to execute a security action on a target, when review by an analyst is required to ensure that security is balanced with business continuity, and when an analyst needs to augment codified decision-making logic (for example when an error occurs).

AERC/PROC/RFP/COM/5502/2020-2021/012

11

9. Case Management

9.1. Once alerts or events are confirmed and escalated, a case management component should drive a broader, cross-functional lifecycle from creation to resolution.

9.2. Seamlessly link the analyst to the alert management interface for the respective alert. From the alert management interface, additional actions can be executed and changes to relevant data should be reflected in the case management interface

9.3 Provide the ability to define stages according to their process and save them as a template. A user should have to ability to break the SOP into multiple stages where each stage has one or more tasks, and each task can be assigned an owner.

10 Automation Editor

10.1 A visual automation editor is where an analyst or manager codifies their processes into automation playbooks packaging SOP’s.

AERC/PROC/RFP/COM/5502/2020-2021/012

12

Annexure‐III

Project Services for Implementation

Sr. No#

Services during Project Implementation

Specifications in Brief Compliance (Yes/ No)

1 End to end Project Management

Project to be implemented by OEM approved supplier only

1. A pre‐BRM session to collect all

information, data required during a 5 day BRM session.

2. Conducting 5 days BRM session preparation of roadmap for business cases (minimum 10), as an outcome of BRM session. Business Requirement Mapping service for review, study of existing scenario and effective integration.

3. Five successful case studies from similar assignments have to be presented during BRM session. BRM session to deliver minimum 10 business cases.

4. Installation & Configuration of SOAR

5. Configuration of Assets, Networks, Locations, Vulnerabilities etc. in SOAR for efficient use of such information in correlation activities.

6. Configuration of following to meet functional requirements

Reports ● Reports as demanded by BRM

Dashboard ● Dashboards as demanded by BRM

Alerts ● Email, SMS alerts to respective

stakeholders based on the threshold triggered & escalation matrix

7. User Acceptance Testing based the UAT document prepared jointly by AERC & Vendor

8. Asist in the development of appropriate security incidence response procedures in

AERC/PROC/RFP/COM/5502/2020-2021/012

13

alignment with related policies

9. Submission of Project documentation & Sign off

2. Training Training, Knowledge transfer session: Hands on SOAR Security Administration, EC-Council’s SOC Analyst training and credentialing for one AERC IT staffer and OSCP Pen testing training and certification for one AERC IT staffer.

AERC/PROC/RFP/COM/5502/2020-2021/012

14

RFP SCHEDULE

Invitation and release of RFP November 30, 2020

Period for Q&A from vendors December 11 - 18, 2020 Deadline for submission of proposal January 8, 2021

Notification of shortlisted vendors and requirements for proof of concept presentation

January 15, 2021

Presentations of proposals and proof of concept to AERC

Week January 18, 2021

PROPOSAL REQUIREMENTS

• The RFP documents and materials should include a company profile including bios of key staff and proposed team; areas of competencies; client list and references; mandatory documents; technical and financial proposal.

• RFP documents and materials shall include items listed above as well as any other documents and materials that may be issued prior to the deadline for submission of proposal.

• 3 to 5 case studies of similar successful implementations, including sample project plan • Your approach to client service and client management; • Five current client references; • Five client work examples that showcase your work for clients both regional and global.

The proposal must be submitted electronically by December 11, 2020 at 17:00/5 pm EAT in Word or PDF format to procurement@aercafrica.org

• Each proposal should be structured in a clear, straightforward manner and in accordance with the outline of the respective sections herein. Service provider(s) should exercise care to present only realistic, attainable commitments in their proposal. Non-compliance to meeting any requirements must be specifically stated with reasons by the Service provider(s).

• All communication between the vendor and AERC shall be through the email address listed below.

• When submitting questions, the identity of the service provider(s) representative must be clearly indicated. The email shall in such cases, follow the format of (1) Name of service provider and (2) Date of submission e.g. Service provider name, date. All questions must be sent to AERC before the deadline indicated above.

Attn: Executive Director

African Economic Research Consortium 3rd Floor, Mebank Towers, Jakaya Kikwete Road P.O Box 62882 – 00200, Nairobi, Kenya Email: procurement@aercafrica.org

Dated: November 30, 2020