Cloud IDS / IPS Considerations in IRAP Assessments

IRAP (Infosec Registered Assessors Program) is a familiar friend to ICT professionals working for / on many government and non-government programs. With the aim to secure ICT systems and data in broader private and public sectors, the Australian Signals Directorate (ASD) endorses suitably qualified cyber security professionals to provide this comprehensively developed security assessment services.

‘Endorsed IRAP assessors assist in securing your systems and data by independently assessing your cyber security posture, identifying security risks and suggesting mitigation measures.

IRAP assessors can provide security assessments of SECRET and below for:

• ICT systems
• Cloud services
• Gateways
• Gatekeeper
• FedLink’

(from cyber.gov.au)

Going through an IRAP assessment journey is rarely a straightforward job - many would wonder if that would be possible at all. It takes considerable efforts by the organisation and their service providers to work with the IRAP assessor to cover a large number of aspects of ‘controls’.

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’ in IRAP, in a cloud setting.

IDS/IPS in cloud environments can be quite different to on premises IDS/IPS solutions. IRAP has its own specific requirements on the so-called network-based IDS or IPS. 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

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.

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 solution-ing a NIDS/NIPS service.

Below are a few cloud NIDS/NIPS considerations - 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.

                                                                                                                                            (Diagram: AWS)

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. Amazon CloudWatch and AWS CloudTrail record comprehensive data on logs of AWS services, events, as well as API and account activity 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 activity, and delivers detailed security findings for visibility and remediation. 

‘GuardDuty combines machine learning, anomaly detection, network monitoring, and malicious file discovery, utilizing 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’

                                                                                                                                                                (Diagram: 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. 

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 (IRAP states that 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 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. 

                                                                                                                                                                            (Diagram: AWS)

Above are just a few considerations on the cloud-based NIDS/NIPS, in the context of an IRAP assessment. Each organisation’s situation is different and what you would like to achieve through an IRAP assessment can also vary a lot. 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.     

                                                                                                                                                  -- Simon Wang