Security Overview

Defense in Depth
The xxxxxxxx VPC has employed the concept of Defense in Depth. Defense in Depth an IT
Security concept (originally drawn from military strategy) in which multiple layers of security
controls are put in place. Its intent is to provide redundancy in the event a single security control
failing or being compromised. The idea behind the defense in depth approach is to defend a
system against attack using several independent methods that are layered on top of each other.
Defense in Depth has been achieved through the use of:

1. A Virtual Private Cloud

2. A Multi-tiered Network Architecture
3. Routing Tables
4. Network ACLs
5. Security Groups

Network Tiering
A multi-tiered network architecture has been employed and is enforced through the use of
Network ACLs. Network ACLs have had to be used because the AWS VPC network is a hub-
and-spoke model by default with all subnets linked via a virtual router. This approach has been
taken to keep Xxxxxxxxxx's data as far away from the internet as possible whilst still making it
available for consumption within the environment and from Xxxxxxxxxx networks where
considered appropriate.

Routing
Route Propagation has been enabled for all subnets/tiers with the exception of the Internet facing
tiers - xxxxxx and xxxxxxxx to allow connectivity from Xxxxxxxxxx networks. Xxxxxxxxxx
networks are considered semi-trusted to the XXXXXXXXXX.
Ingress
From the Internet
All traffic from the Internet is considered to have come from a non-trusted source, whether it has
originated from an Xxxxxxxxxx network or not. The below measures are applied to all non-trusted
traffic.
All connectivity from the Internet must come into the xxxxx_xxxx network tier via an Internet
Gateway attached to the VPC. The connection must be terminated on a host/service in the
xxxx_xxx network tier before a new connection is established from the xxxxx_xxxx tier to a host
or service in xxxx or xxxx_xxx tier. The host/service in the xxxx or xxxx_xxxx tier must then
connect to a host or service in the xxxx or xxxx_xxxx. There is no direct connectivity from the
xxxx_xxxx or xxxx/xxxx_xxxx tiers to the xxxx tier and this is enforced through the use of Network
ACLs.

From Xxxxxxxxxx Networks

Even though network traffic originating from Xxxxxxxxxx networks can be considered to be from
a trusted source, the inherent security capabilities of AWS allow this traffic is treated as semi-
trusted and this is the default stance for all network access control within the XXXXXXXXXX.
All connectivity from Xxxxxxxxxx networks comes via VPN from a Cisco ASA hosted in the
Xxxxxxxxxx Skondal data centre. For the most part, administrative access to servers must come
via a Bastion host within the Management tier of the VPC. The other tiers provide various servers
(web, application, data) that are directly accessible from Xxxxxxxxxx networks - although this
access must be explicitly defined in Security Groups for the various services being presented.

Egress
To the Internet
Non-NATted Subnets
The default configuration for all subnets within the environments is to have no direct or indirect
access to the Internet whatsoever. The exceptions to this rule are:

xxxxxx - direct access to the internet where an EIP has been bound to a host/service
xxxxxx - direct access to the internet where an EIP has been bound to a host/service
xxxxxx - indirect access to the internet via a managed AWS NAT gateway. NAT is restricted to
AWS ranges of IPs only. Nothing else outside of these IPs is accessible using NAT.
xxxxxx - indirect access to the internet via a managed AWS NAT gateway. NAT is restricted to
AWS ranges of IPs only. Nothing else outside of these IPs is accessible using NAT.

Any host that falls outside of the above exceptions that requires access to an external internet
hosted source (for patching, product updates etc) must connect via a Forward Proxy server
hosted in the xxxx network tier. The Forward Proxy is configured with a whitelist of known and
approved URLs and anything not on the whitelist is implicitly denied. URLs are only added to the
whitelist after a Service Now ticket has been received and the request passed through an
approval process. All requests via the Forward Proxy servers are currently logged and the logs
retained indefinitely.

NATted Subnets
Currently there are only two NATted zones within the environment. NAT has been identified as a
requirement because the ElasticBeanstalk service cannot currently use a Forward Proxy server
to connect to all the external AWS endpoints that it needs to connect to. These zones are:

xxxxxxx
xxxxxxx

These zones have been restricted to AWS IP addresses only. Where a host within these zones
need to connect to something other than AWS Service endpoints, they must still make use of the
Forward Proxy servers for outbound connectivity.

To Xxxxxxxxxx Networks
All traffic to Xxxxxxxxxx networks goes via the Virtual Private Gateway attached to the VPC and
down a VPN connection terminating on a Cisco ASA in the xxxxxx data centre. All traffic from the
XXXXXXXXXX into Xxxxxxxxxx networks is currently treated as trusted and no additional access
requests need to be made to allow connectivity.