I feel that there is always plenty to talk about on IRAP. In this tech piece, I would like to touch on the topic of ‘Using Network-based Intrusion Detection and Prevention Systems’ (NIDS/NIPS) in IRAP, in a cloud setting to secure cloud environments, as a requirement in compliance programs.
IDS/IPS in cloud environments can be quite different to on premises IDS/IPS solutions. For enterprise and government customers, and there can be a range of difference compliance checks that requirements organisations are required to meet. NIDS / NIPS are one of such mandatory requirements. For example, when implementing controls from the Australian Cyber Security Centre's Information Security Manual (ACSC ISM) IRAP, has its own specific their requirement focuses on the so-called network-based IDS or IPS has following key point. One of the key points to observe is:
- NIDS or NIPS are to monitor unusual patterns of behaviour or traffic flows rather than internet-based communication protocol signatures
Currently, this control comes under the infrastructure banner. One day IRAP may develop specific controls for cloud environments. Right now, it is all under the banner of infrastructure. What it means, from the above key point, is that the NIDS or NIPS is to be deployed inside of the most external firewall for monitoring the ‘unusual patterns of behaviour or traffic flows’ traversing the internal infrastructure. (This was a specific call out by the independent compliance assessor for an IRAP compliance program where I was helping a customer going through an IPAP compliance program.)
In a cloud setting, this typically means everywhere inside the WAF (Web Application Firewall, aka the Internet facing defence line).
Unlike on-premises, a cloud-based environment shows strong characteristics of virtual, distributed, systems – cloud firewalls are not one or two hardware boxes; cloud routers and switches do not have ports or network cables connected; and deploying a number of new networks / resources can be just a few clicks away. The networking equipment is virtually everywhere, on everything. Due to all these abstraction factors, various takes or angles exist on solutioning a NIDS/NIPS service.
Below are a few cloud NIDS/NIPS considerations in line with the above mentioned compliance context - vastly different in their approaches.
Traffic Mirroring + Sensor Software on Instances
Traditionally, on premises IDSs are appliance or host-based hardware with specialised sensor software installed. Then, network switches are configured to mirror all traffic to the port where the IDS box connects to.
This approach can still be realised in cloud solutions.
For example, Amazon VPC Traffic Mirroring is a service that can copy network traffic from an elastic network interface and then send the traffic to virtual out-of-band security and monitoring appliances for:
- Content inspection
- Threat monitoring
- Troubleshooting
The virtual security and monitoring appliances can be deployed as individual instances, or as a fleet of instances behind either a Network Load Balancer with a UDP listener or a Gateway Load Balancer with a UDP listener.
The traffic mirror source and the traffic mirror target (the virtual monitoring appliance) can be in the same VPC. Alternatively, they can be in different VPCs that are connected through intra-Region VPC peering, a transit gateway, or by a Gateway Load Balancer endpoint to connect to a Gateway Load Balancer in a different VPC.
The AWS diagram below depicts how traffic to and from A, as well as traffic to and from B, are all sent to target D where an instance (or a fleet of instances) with IDS sensor software locates.
The sensor software is typically some specialised third-party software. There are such options / solutions on AWS marketplace.
Any findings that require further actions can be reported by the software to the organisation’s SIEM (Security Information and Event Management system).
Cloud Logs + Security Hub
Modern clouds offer comprehensive logging and monitoring on pretty much every aspect. Modern clouds also offer comprehensive log data analysing capabilities, often in near real time. Such comprehensiveness is something that non-cloud environments can rarely match.
By leveraging such logging and analysing capabilities, it can be considered that a distributed, whole system wide, virtual IDS can be configured using modern clouds’ built-in tools and services.
Let’s use AWS cloud as an example. Amazon VPC Flow Logs capture information about the IP traffic going to and from network interfaces in the VPC. There are also ELB logs, S3 bucket logs, CloudFront access logs, Route 53 query logs, and logs for many other AWS managed services, just to mention a few. Amazon CloudWatch and AWS CloudTrail record comprehensive data on logs of AWS services, events, as well as logs for API and account activities logs. All such data is just like the data collection component of an IDS. (Please do note that differences exist – logging does not provide single packet level data collection, rather it is typically at the per flow level.)
Amazon GuardDuty, part of AWS Security Hub, offers intelligent threat detection by continuously monitoring the AWS accounts and workloads for malicious activities, and delivers detailed security findings for visibility and remediation.
‘GuardDuty combines machine learning, anomaly detection, network monitoring, and malicious file discovery, utilising both AWS-developed and industry-leading third-party sources to help protect workloads and data on AWS. GuardDuty is capable of analysing tens of billions of events across multiple AWS data sources, such as AWS CloudTrail event logs, Amazon Virtual Private Cloud (VPC) Flow Logs, Amazon Elastic Kubernetes Service (EKS) audit logs, and DNS query logs. - AWS’
Amazon GuardDuty generates findings to flag potential security issues through detection of unexpected and suspicious activities within the network.
Each GuardDuty finding carries an assigned severity level value – the higher the value, the higher the potential risk. The range of severity level values is: 0.1 ~ 8.9.
GuardDuty Findings (High and Medium levels) and select CloudWatch alarms can be the ‘trigger alerts’ from the virtual, distributed IDS. There are other security services in AWS Security Hub as well. These triggers can be sent to the SIEM for further actions. Here we have the analysing, reporting, alerting, and responding components of an NIDS.
Automated remediation actions using native AWS tools such as Lambda can also be implemented.
Network Firewall
This is yet another consideration: place network firewalls inside the WAF (as discussed earlier ACSC ISMIRAP states that NIDS/NIPS to be placed inside of the most external firewall), have the network firewalls inspecting all traffic -– it can be regarded as a virtual, distributed NIPS, while being a stateful firewall.
In AWS’s case, AWS Network Firewall has a built-in intrusion prevention system that inspects traffic flows with real-time network and application layer protections against vulnerability exploits. Known threat attributes such as byte sequences and packet anomalies are identified by the signature-based detection engine.
The AWS diagram below shows how the Network Firewall, when done with desired placement and routing configured accordingly, can inspect and filter all traffic that an organisation concerns about: inbound, outbound, inter VPC, as well as traffic with on premises or VPN connections.
Above are just a few considerations on the cloud-based NIDS/NIPS, in the context of an IRAP assessmentACSC ISM compliances. Each organisation’s situation is different and what you would like to achieve through an IRAP assessment can also vary a lot. Logically, the most suitable NIDS/NIPS IRAP proposition is case by case, scenario by scenario. Regardless of the approach, comprehensiveness in considerations will give you the best position when working with the IRAP assessor.