Mantel Group partnered with a large Australian Health Insurance provider seeking to deliver a cloud-native adoption program to achieve both the financial efficiency and security benefits associated with decommissioning infrastructure gain innovation benefits of using cloud-native services.
INDUSTRY
Financial Services and Security
SERVICES
Security Uplift
Services we provided
Security uplift
In partnership with the customer, Mantel Group supported the delivery of Cloud adoption part of the Customers strategic direction part of a multi-year cloud adoption journey gaining the transformational benefits of various cloud technologies. The cloud-native AWS platform has underpinned digital transformation and enablement using well-understood secure cloud architecture patterns.
Key Results
The customer’s AWS workload became a more secure environment where access from the data tier to the public internet is restricted to the minimum possible IPs while all other traffic goes through VPC endpoints. In addition, all data is encrypted both at rest and in transit with mutual TLS in place for any application access. This means that this particular environment is more secure, but as everything was built to be reusable, these benefits were subsequently shared with multiple environments with minimal effort.
Company Overview
The client is a trusted international health partner, empowering their members to make better decisions and improve health outcomes through greater accessibility to affordable health services and information.
They also provide health and medical insurance to over 1.6 million Australian and New Zealand residents. They also provide health insurance to around 200,000 international students and workers in Australia.
The Problem
To improve their security posture, the client required the security of their system of record environment to be updated. The main application in use is third-party software that isn’t designed for modern cloud environments, and includes a non-standard database. The focus was to prevent data exfiltration and unauthorised access to the underlying systems.
The Solution
Together with the client we identified key areas that needed improvement, and came up with solutions for each of these areas.
For encryption, certificates generated using Private Certificate Authority ensure valid TLS certificates are in place. In addition, mTLS is enabled by way of having this configured in the IIS server of the applications that require it. mTLS client certificates are issued to trusted applications, and a TLS server certificate are issued to the relevant IIS server(s). The IIS server are configured to require mutual authentication, so that the client validates the server has a trusted certificate, and the server validates that the client has a trusted certificate before the encrypted connection is established. Once the mTLS connection is established, the API operates without any other change.
A private Certificate Authority (CA) is created to issue and sign client certificates, and manage the certificate lifecycle.
All file systems are encrypted using CMK KMS keys, to provide encryption at rest. This results in encryption of both the running instances as well as the regularly managed snapshots.
For communication with AWS services, interface endpoints are created for each respective service, and these are configured with private DNS. The exception for this is S3, where the private DNS entries are managed separately through infrastructure as code. All of these endpoints are deployed in the private subnet and accessible from the data tier.
Crowdstrike Falcon is in place as an IDP, and this reports back to Crowdstrike’s control servers using a private endpoint. As the endpoint on the Crowdstrike side could only be deployed in the us-west-1 (California) region, traffic to this private endpoint goes through a peered Transit Gateway to a dedicated VPC. This VPC only has a Transit Gateway attachment and the private endpoint. The VPC also has a private hosted zone with the relevant DNS entries that is shared with all the relevant VPCs. The below diagram shows how this connection works.
Other services that cannot be managed by way of VPC endpoints, such as OS registration and update services for instances in the data tier, have exceptions made in the outbound NACL rules and route tables. All this traffic from the data tier goes through a proxy NAT Gateway running in the private tier. The IP ranges are stored in self-managed prefix lists in a centralised account that are shared with the Organization through Resource Access Manager.
Key Products/Services we used
Outcomes
All these changes were successfully implemented and are working as intended. Flow logs and routing checks show that the network related changes work correctly and For all the network related changes, these were verified with both manual and automated tests to be correct now at the end, and the encryption items were all verified too with 100% of the environment using encryption both in transit and at rest.
Lessons Learned
There were a number of lessons learned. Worth mentioning:
- Using mTLS means we can’t use SSL termination on the NLB, and instead had to configure this in IIS.
- Logging useful metrics and creating CloudWatch alarms to capture mTLS connection data in the IIS logs required additional custom Powershell scripting in ec2 UserData.
- Discovered that subordinate certs in the chain must have an expiry date no less than the maximum period of the issued end cert. Additional CloudWatch custom metrics and alarms were created to detect expired certificates as a result.
- Setting up Transit Gateway peering correctly is an interesting challenge
