RFG Nokia Securty response 22 Dec 2015

RFG response for Nokia security evaluation

The document below provides information requested for response to the Nokia security evaluation:

# Nokia Requirements Section
1 CERT reactive security incidents/e-investigation/lockout 1.7
2 CERT proactive vulnerability management IDS/IPS 1.5
3 Awareness security education/training 1.6
4 User access IAM integration, RBAC, joiner&leaver 1.6
5 Privileged access jump server, segregation of duties 1.6
6 Customer data data at rest – segregation /encyption, key owner 1.4
7 Application secure coding/configuration - OWASP 1.1
8 Platform DNS, webserver, database, backup, certificate
9 Computing HW,OS, firewall , malware protection, patching 1.3
10 Connectivity data in motion protection /encyption 1.2
11 Disaster recovery redundancy, backup, failover 1.4
12 Safety & Person Sec.surveillance, physical access, joiner&leaver 1.8
1.9
Environmental Sec.power,cooling, fire, water, protection

1.1.Application

ComplianceDesktop® | Anti-Corruption Compliance Platform is an enterprise compliance
management portal, that manages the key areas of the anti-corruption compliance programme.

The platform has been developed by RFG’s in-house development team. The Platform is built on top
of a range of open source technologies, predominantly PHP and MySQL. We also use third party
software such as LogiInfo to power the reporting module.

All clients receive a standard platform and are on a standard release cycle. Feature enhancements to
the platform are handled by the RFG Technology Products Team who review new feature requests
determine whether they are generally applicable to all clients based on the provisional business
prioritisation and assign to Business Analysts for design.

The Business Analysts discuss the business requirement with the development team and identify
technical solutions, challenges and/or impacts which need to be allowed for as part of the Product
Design Specification document for the proposed change request.

The draft Product Design Specification will then be reviewed by the Products Team. The assigned
Business Analyst will incorporate feedback on an iterative basis to provide a final design specification
and initial estimate of the development resources required to deliver the feature change request.

The Products Team will then carry out a reprioritisation of all confirmed feature designs for review by
the business and approved by the Vice President of Products.

1

RFG response for Nokia security evaluation

The prioritised Feature Design Specifications are then available to the Development Team for
development, and the QA teams for the creation of test cases. Future feature releases are
incorporated into the product road map.

1.1.1. Secure SDLC

RFG utilises a comprehensive SDLC life cycle, covering: Requirements Gathering, Design, Coding,
Testing and Deployment.
Each SDLC function has dedicated resources and team providing a comprehensive governance
framework for development.
All development is carried out on isolated server environments segregated by function: DEV, QA, and
Client Environments: UAT and PRODUCTION.

1.2.Platform

Clients can elect to host the application themselves, or use a ‘Managed Hosting Service’ from RFG.
The majority of clients, including ALU elect to use the managed hosting option. Where RFG provides
the hosting, the application is hosted on Amazon Web Services (AWS) (formerly RFG used Rackspace
for hosting services). All clients are contracted with RFG not AWS.
The primary services provided by AWS are:

 Elastic Compute Cloud (EC2) which provides server access, and
 Relational Database Service (RDS) which provides the database (MySQL).
 Simple Storage Service (S3) which manages the backup of data
The two standard hosting packages available from RFG:

1. Shared Cloud Hosting Environment. The ComplianceDesktop® environment is hosted in a multi-
tenant cloud hosting environment. AWS EC2 and RDS are utilized and shared by multiple clients

2. Standalone Cloud Hosting Environment. The ComplianceDesktop® environment is hosted in a
single-tenant cloud hosting environment. AWS EC2 and RDS are fully utilized by your company
only.

Application performance is the responsibility of RFG. Normal service reviews, and alert and
monitoring, such as LogicMonitor, are in place and reviewed regularly. These monitoring tools, in
place at AWS, provide input into the review process.

Application performance is the responsibility of RFG. We conduct normal service reviews, have alert
and monitoring systems in place. Monitoring tools from the AWS platform provide input into the
reviews.
All file and database backups are encrypted with daily full backup with a 30 day retention period. All
backup files use AWS S3 for storage. No backups are stored on the actual server. AWS S3 is designed
with 99.99% availability and 99.999999999% durability. By default, this service automatically
replicates any S3 object to multiple locations within the region. Upon client request for standalone

2

RFG response for Nokia security evaluation

hosting, we can enable Cross-region replication (CRR) to backup any object to a destination bucket in
a different AWS region that our client chooses.1
The standard hosting platforms currently use Amazon Linux AMI release 2015.09. Antivirus software
managed by RFG is ClamAV 0.98 and is deployed on all servers.

1.3.Firewalls

Every virtual server (EC2 instance) and VPC contains a firewall (AWS security group) which restricts
access to the instance involved.
Below is an example of the associated “firewall” rules

In addition, RFG also uses and manages a Barracuda Web Application Firewall for comprehensive Web
application and Web services security, access control, and application acceleration for our Web based
applications, which:

1. Detects and blocks SQL injections, Cross-Site Scripting, malware uploads, volumetric &
application DDoS, or any other attacks against our application.

2. Authenticates and provides access control functions to provide strong authentication and
user control.

3. Scans outbound traffic to detect sensitive data and can either mask or block the information
from being leaked out.

As a final security measure, all AWS facilities include a perimeter network firewall security managed
by AWS.
IP whitelisting is available and can be provided via the security group configuration, web application
firewall and Apache configuration. For clients with Single Sign On services, it also occurs based on
context for the application itself.

1.4.Data encryption

1 S3 FAQ: https://aws.amazon.com/s3/faqs/. S3 SLA: https://aws.amazon.com/s3/sla/

3

RFG response for Nokia security evaluation

RFG provides data encryption in transit and at rest. For encrypting data at rest, RFG uses the default
encryption provided by AWS. The encryption method is AES 256 with key management run by RFG
using the AWS KMS. (Note this only applies to AWS hosted services. For ALU, once transferred to AWS
from Rackspace, RFG will create a dedicated encryption key and store the key in AWS KMS. This key
will be used for all client encryption instances and rotated annually.)
Data in transit to a client production compliancedesktop.com site is via HTTPS, using an SSL certificate
from GoDaddy, managed by RFG. Test sites for clients can be configured to allow HTTP access if
required. Production sites which are accessed via http redirect to the https site.
For any file loads to a client site (such as an HR feed), SFTP is used with the login certificate (public
key) provided by the client.

1.5.Vulnerability management

RFG runs a regular penetration test using a third party vendor Trustwave. The next test, scheduled
for Q1 2016, will be the first using the AWS infrastructure.
Software vulnerability reviews are carried out on a quarterly basis by Trustwave and RFG’s security
team.

1.5.1. Patching

Server patching is carried out by RFG infrastructure team based on results from Trustwave and using
the regular review basis, prioritising patches and risks. RFG has a maintenance window agreed with
clients, although significant security patches may be installed outside of those windows.
Minor version database patching is done by AWS, the RDS service is managed by AWS, within agreed
maintenance windows.

1.5.2. IDS/IPS

AWS provides and manages the Perimeter Network IDS/IPS.
The application IDS/IPS is provided by the Barracuda web application firewall as documented above.

1.5.3. Monitoring

Monitoring and log management are carried out via a number of services, including:
1. AWS Cloud Watch for EC2 and RDS
2. AWS CloudTrail for low level application loggings.
3. Zabbix for syslog monitoring.

The Barracuda WAF has its own monitoring module and this configured to use the alerting features
for operational monitoring.

1.6.Identity Access Management

1.6.1. User access

ComplianceDesktop® offers two main ways to manage user access to the application. The application
administrator can add, edit or inactivate users via the application front-end interface.

4

RFG response for Nokia security evaluation

Alternatively, for clients who subscribe to our HR Feed services, the client can automatically send us
their employee data file to our SFTP server and we then import, update or remove inactive users based
on the data provided. This process is fully automated once setup and configuration completed.
For Infrastructure and system level, user access requests are created within our internal Jira ticket
system. Each request is reviewed and approved by the Infrastructure Manager. The user
creation/modification is carried out by our internal system operation (Sysops) team and ticket closure
is confirmed by successful completion by the requestor.

1.6.2. Privileged access

Privileged access for Infrastructure and system level also requires a user access request to be created
within our internal Jira ticket system. Each request is again reviewed and approval granted by the
Infrastructure Manager. The privileged user creation/modification is carried out by our internal Sysops
team and ticket closure is confirmed by successful completion by the requestor.

1.6.3. Staff leaving process

For any staff who leave the firm, the HR function provides a request to IT service desk to remove
access. This includes provides a checklist of services to be removed or inactivated – including access
to ComplianceDesktop sites and infrastructure.

1.6.4. Training

As a compliance firm, all RFG staff receive annual training on Compliance topics. This includes a
number of topics, but specifically data protection and data privacy awareness. New starters receive
the training as part of their induction (within the first month of commencement).
The development and infrastructure teams also receive specific security training. All senior staff in
these roles received ISO27001 training in Feb 2015 as well as AWS training in May 2015 for those
involved in the migration. Service desk staff also received ITIL v3 training in 2015.

1.7.Security Incident management

Information security weaknesses and events are reported, immediately when they are seen or
experienced, by one of the following 3 methods:

1. submit ticket in RFG Service Desk ticketing system
2. email to [email protected]
3. or telephone to the Service Desk

The following core information is recorded:
o Date/Time
o System
o Description of weakness or event.

All incidents, information security events and weaknesses, immediately upon receipt, are assessed
and categorized by the I.T. Team. All incidents are then ascribed a Severity level from 1-4 (1 – Critical,
4 – No impact).

5

RFG response for Nokia security evaluation

If a high priority incident occurs and causes business impact or a security issue, the Service Desk,
Corporate I.T. informs the Practice Head of Information Technology.
All events are dealt with by the documented RFG Incident Management process.

1.8 DR

For our database systems, RFG makes use of the Multi-AZ (Availability Zone) feature from AWS. Under
this feature Amazon RDS automatically creates a primary DB Instance and synchronously replicates
the data to a standby instance in a different Availability Zone (AZ). Each AZ runs on its own physically
distinct, independent infrastructure, and is engineered to be highly reliable. In case of an
infrastructure failure (for example, instance hardware failure, storage failure, or network disruption),
Amazon RDS performs an automatic failover to the standby, so that you can resume database
operations as soon as the failover is complete. Since the endpoint for your DB Instance remains the
same after a failover, your application can resume database operation without the need for manual
administrative intervention.
For our servers, we use a daily backup process, based on imaging of the server, with the images stored
in cloud storage with high redundancy. During a DR event, a new instance is instigated in the same
region, as previously specified with the client, and restored from the last backup image.
The agreed RTO and RPO are 2hrs and 1 day respectively.

1.9 Physical security

AWS data centres are housed in nondescript facilities. Physical access is strictly controlled both at the
perimeter and at building ingress points by professional security staff utilizing video surveillance,
intrusion detection systems, and other electronic means. Authorized staff must pass two-factor
authentication a minimum of two times to access data centre floors. All visitors and contractors are
required to present identification and are signed in and continually escorted by authorized staff.
AWS only provides data centre access and information to employees and contractors who have a
legitimate business need for such privileges. When an employee no longer has a business need for
these privileges, his or her access is immediately revoked, even if they continue to be an employee of
Amazon or Amazon Web Services. All physical access to data centres by AWS employees is logged and
audited routinely
RFG has no physical access to the AWS data centres.

6