Australian Commonwealth Government agencies are at the mercy of specific requirements set by the Protective Security Policy Framework (PSPF) for securing connectivity between systems which are running sensitive workloads, and for accessing less trusted environments, like the internet. These agencies have often met certain requirements by using some type of approved gateway solution that delivers network-based security controls.

        <p>This post examines the forms of controls you need to supply a gateway that may meet Australian Government requirements defined in the <a href="https://www.protectivesecurity.gov.au/information/robust-ict-systems/Pages/default.aspx" target="_blank" rel="noopener noreferrer">Protective Security Policy Framework (PSPF)</a> and the challenges of using traditional deployment models to aid cloud-based solutions. PSPF requirements are mandatory for non-corporate Commonwealth entities, and represent better practice for corporate Commonwealth entities, wholly-owned Commonwealth companies, and state and territory agencies. We discuss the capability to deploy gateway-style solutions in the cloud, and show ways to meet the most gateway requirements through the use of standard cloud architectures plus services. We provide help with deploying gateway solutions in the AWS Cloud, and highlight services that may support such deployments. Finally, we offer an illustrative AWS web architecture pattern showing how to meet up with the most gateway requirements through Well-Architected usage of services.</p> 

Australian Government gateway requirements

The Australian Government Protective Security Policy Framework (PSPF) highlights the necessity to use secure internet gateways (SIGs) and references the Australian Information Security Manual (ISM) control framework to steer agencies. The ISM includes a chapter on gateways, which include the following tips for gateway architecture and operations:

• Give a central control point for traffic in and from the system.
• Filter and inspect traffic.
• Monitor and log traffic and gateway operation to a secure location. Use appropriate security event alerting.
• Use secure administration practices, including multi-factor authentication (MFA) access control, minimum privilege, separation of roles, and network segregation.
• Perform appropriate authentication and authorization of users, traffic, and equipment. Use MFA when possible.
• Use demilitarized zone (DMZ) patterns to limit usage of internal networks.
• Test security controls regularly.
• Setup firewalls between security domains and public network infrastructure.

Because the PSPF references the ISM, the agency should apply the entire ISM framework to meet up ISM requirements such as for example governance and security patching for the surroundings. The ISM is really a risk-based framework, and the chance posture of the workload and organization should inform how exactly to assess the controls. For example, requirements for authentication of users may be relaxed for a public-facing website.

In traditional on-premises environments, some Australian Government agencies have mandated centrally assessed and managed gateway capabilities to be able to drive economies of scale across multiple government agencies. However, the PSPF does supply the option for gateways used only by way of a single government agency to attempt their very own risk-based assessment for the single agency gateway solution.

Other government agencies likewise have specific requirements for connecting with cloud providers. For instance, the U.S. Government Office of Management and Budget (OMB) mandates that U.S. government users access the cloud by way of a specific agency connection.

Connecting to the cloud through on-premises gateways

Given the existence of managed off-cloud gateways, one approach by customers has gone to continue steadily to use these off-cloud gateways and hook up to AWS through the on-premises gateway environment through the use of AWS Direct Connect, as shown in Figure 1.

Although this process does work, and employs existing gateway capability, it includes a amount of downsides:

• A potential single point of failure: If the on-premises gateway capability is unavailable, the agency can lose connectivity to the cloud-based solution.
• Bandwidth limitations: The agency is bound by the capability of the gateway, which can not need been developed with dynamically scalable and bandwidth-intensive cloud-based workloads at heart.
• Latency issues: The necessity to traverse multiple network hops, as well as the gateway, will introduce additional latency. This is particularly problematic with architectures that involve API communications being repaid and forth over the gateway environment.
• Castle-and-moat thinking: Relying only on the gateway because the security boundary can discourage agencies from using and recognizing the cloud-based security controls that exist.

A few of these challenges are discussed in the context folks Trusted WEB CONNECTION (TIC) programs in this whitepaper.

Moving gateways to the cloud

In reaction to the limitations discussed within the last section, both customers and AWS Partners have built gateway solutions on AWS to meet up gateway requirements while remaining fully within the cloud environment. See this sort of solution in Figure 2.

With this particular approach, it is possible to fully leverage the scalable bandwidth that’s available from the AWS environment, and you may also reduce latency issues, particularly if multiple hops to and from the gateway are needed. This blog post describes a pilot program in america that combines AWS services and AWS Marketplace technologies to supply a cloud-based gateway.

You should use AWS Transit Gateway (released following the referenced pilot program) to supply the choice to centralize this type of gateway capability in a organization. This can help you make use of the gateway across multiple cloud solutions which are running within their own virtual private clouds (VPCs) and accounts. This process also facilitates the principle of the gateway being the central control point for traffic flowing in and out. To find out more on using AWS Transit Gateway with security appliances, start to see the Appliance VPC topic in the Amazon VPC documentation.

Recently, AWS has released additional services and features that can help with delivering government gateway requirements.

Elastic Load Balancing Gateway Load Balancer supply the capacity to deploy third-party network appliances in a scalable fashion. With this particular capability, it is possible to leverage existing investment in licensing, use familiar tooling, reuse intellectual property (IP) such as for example rule sets, and reuse skills, because staff already are been trained in configuring and managing the chosen device. You have one gateway for distributing traffic across multiple virtual appliances, while scaling the appliances along based on demand. This reduces the potential points of failure in your increases and network availability. Gateway Load Balancer is really a straightforward solution to use third-party network appliances from industry leaders in the cloud. You take advantage of the top features of the unit, while Gateway Load Balancer makes them automatically scalable and better to deploy. You’ll find an AWS Partner with Gateway Load Balancer expertise on the AWS Marketplace. To find out more on combining Transit Gateway and Gateway Load Balancer for a centralized inspection architecture, see this blog post. The post shows centralized architecture for East-West (VPC-to-VPC) and North-South (internet or on-premises bound) traffic inspection, plus processing.

To help expand simplify this area for customers, AWS has introduced the AWS Network Firewall service. Network Firewall is really a managed service which you can use to deploy essential network protections for the VPCs. The service is easy to create and scales automatically together with your network traffic and that means you don’t have to be worried about deploying and managing any infrastructure. It is possible to combine Network Firewall with Transit Gateway to create centralized inspection architecture models, such as for example those described in this blog post.

Reviewing an average web architecture in the cloud

Within the last section, you saw that SIG patterns could be created in the cloud. Now we are able to put that in context with the layered security controls which are implemented in an average web application deployment. Look at a web application hosted on Amazon Elastic Compute Cloud (Amazon EC2) instances, as shown in Figure 3, within the context of other services that may support the architecture.

Although this example doesn’t add a traditional SIG-type infrastructure that inspects and controls traffic before it’s delivered to the AWS Cloud, the architecture has lots of the technical controls which are needed in SIG solutions due to utilizing the AWS Well-Architected Framework. We’ll now step through a few of these services to highlight the relevant security functionality that every provides.

Network control services

Amazon Virtual Private Cloud (Amazon VPC) is really a service you should use to launch AWS resources in a logically isolated virtual network that you define. You have complete control over your virtual networking environment, including collection of your own Ip range, creation of subnets, and configuration of route network and tables gateways. Amazon VPC enables you to use multiple layers of security, including security groups and network access control lists (network ACLs), to greatly help control access to Amazon EC2 instances in each subnet. Security groups become a firewall for associated EC2 instances, controlling both outbound and inbound traffic at the instance level. A network ACL can be an optional layer of security for the VPC that acts as a firewall for controlling traffic in and out of 1 or more subnets. You may setup network ACLs with rules much like your security groups to include yet another layer of security to your VPC. Find out about the precise differences between security groups and network ACLs.

Having this degree of control through the entire application architecture has advantages over relying only on a central, border-style gateway pattern, because security groups for every tier of the application form architecture could be locked right down to only those ports and sources necessary for that layer. For instance, in the architecture shown in Figure 3, only the application form load balancer security group allows website traffic (ports 80, 443) from the web. The web-tier-layer security group would only accept traffic from the load-balancer layer, and the database-layer security group would only accept traffic from the net tier.

If you want to give a central point of control with this particular model, you should use AWS Firewall Manager, which simplifies the administration and maintenance of one’s VPC security groups across multiple accounts and resources. With Firewall Manager, it is possible to configure and audit your security groups for the organization utilizing a single, central administrator account. Firewall Manager applies rules and protections across your accounts and resources automatically, even while you add new resources. Firewall Manager is specially useful when you wish to protect your complete organization, or in the event that you frequently add new resources that you would like to protect with a central administrator account.

To aid separation of management plan activities from data plane aspects in workloads, agencies may use multiple elastic network interface patterns on EC2 instances to supply another management network path.

Edge protection services

In the example in Figure 3, several services are accustomed to provide edge-based protections while watching web application. AWS Shield is really a managed distributed denial of service (DDoS) protection service that safeguards applications which are running on AWS. AWS Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency, so there’s you don’t need to engage AWS Support to reap the benefits of DDoS protection. You can find two tiers of AWS Shield: Standard and Advanced. By using Shield Advanced, it is possible to apply protections at both Amazon CloudFront, Amazon application and EC2 load balancer layers. Shield Advanced also offers you 24/7 usage of the AWS DDoS Response Team (DRT).

AWS WAF is really a web application firewall that helps protect your online applications or APIs against common web exploits that may affect availability, compromise security, or consume excessive resources. AWS WAF offers you control over how traffic reaches your applications by helping you to create security rules that block common attack patterns, such as for example SQL injection or cross-site scripting, and rules that filter specific traffic patterns that you define. Again, it is possible to apply this protection at both Amazon CloudFront and application load balancer layers inside our illustrated solution. Agencies may also use managed rules for WAF to reap the benefits of rules developed and maintained by AWS Marketplace sellers.

Amazon CloudFront is really a fast content delivery network (CDN) service. CloudFront integrates with&amp seamlessly;nbsp;AWS Shield, AWS WAF, and Amazon Route 53 to greatly help protect against multiple forms of unauthorized access, including application and network layer DDoS attacks.

Monitoring and logging services

The example application in Figure 3 shows several services offering logging and tabs on network traffic, application activity, infrastructure, and AWS API usage.

At the VPC level, the VPC Flow Logs feature offers you the capability to capture information regarding the IP traffic likely to and from network interfaces in your VPC. Flow log data could be published to Amazon CloudWatch &lt or logs;a href=”http://aws.amazon.com/s3″ target=”_blank” rel=”noopener noreferrer”>Amazon Simple Storage Service (Amazon S3). Traffic Mirroring is really a feature which you can use in a VPC to fully capture traffic if necessary for inspection. This enables agencies to implement full packet capture on a continuing basis, or in reaction to a particular event within the application form.

Amazon CloudWatch offers a monitoring service with alarms and analytics. In the example application, AWS WAF may also be configured to log activity as described in the AWS WAF Developer Guide.

AWS Config offers a timeline view of the configuration of the surroundings. You can even define rules to supply alerts and remediation once the environment moves from the desired configuration.

AWS CloudTrail is really a service which you can use to handle governance, compliance, operational auditing, and risk auditing of one’s AWS account. With CloudTrail, it is possible to log, monitor continuously, and retain account activity that’s linked to actions across your AWS infrastructure.

Amazon GuardDuty is really a threat detection service that continuously monitors for malicious activity and unauthorized behavior to safeguard your AWS accounts. GuardDuty analyzes tens of vast amounts of events across multiple AWS data sources, such as for example AWS CloudTrail event logs, Amazon VPC Flow Logs, and DNS logs. This blog post highlights a third-party assessment of GuardDuty that compares its performance to other intrusion detection systems (IDS).

Route 53 Resolver Query Logging enables you to log the DNS queries that originate in your VPCs. With query logging fired up, you can view which domain names have already been queried, the AWS resources that the queries originated-including source IP and instance ID-and the responses which were received.

With Route 53 Resolver DNS Firewall, it is possible to filter and regulate outbound DNS traffic for the VPCs. To get this done, you create reusable collections of filtering rules in DNS Firewall rule groups, associate the rule groups to your VPC, and monitor activity in DNS Firewall logs and metrics. In line with the activity, it is possible to adjust the behavior of DNS Firewall accordingly.

Mapping services to regulate areas

In line with the above description of the usage of additional services, we are able to summarize which services donate to the control and recommendation areas in the gateway chapter in the Australian ISM framework.

Recommendation and control areas	Contributing services
Filter and inspect traffic	AWS WAF, VPC Traffic Mirroring
Central control point	Infrastructure as code, AWS Firewall Manager
Authentication and authorization (MFA)	AWS Identity and Access Management (IAM), application and solution IAM, VPC security groups
Monitoring&lt and logging;/td>	Amazon CloudWatch, AWS CloudTrail, AWS Config, Amazon VPC (flow logs and mirroring), load balancer logs, Amazon CloudFront logs, Amazon GuardDuty, Route 53 Resolver Query Logging
Secure administration (MFA)	IAM, directory federation (if used)
DMZ patterns	VPC subnet layout, security groups, network ACLs
Firewalls	VPC security groups, network ACLs, AWS WAF, Route 53 Resolver DNS Firewall
Web proxy; site and content scanning&lt and filtering;/td>	AWS WAF, Firewall Manager

Remember that the listed AWS service may not provide all relevant controls in each area, and it is area of the customer’s risk assessment and design to find out what additional controls may need to be implemented.

As you can plainly see, lots of the recommended practices and controls from the Australian Government gateway requirements already are encompassed in an average Well-Architected solution. The implementing agency gets the selection of two options: it could continue to place this type of solution behind a gateway that runs either within or beyond AWS, leveraging the gateway controls which are inherent in the application form architecture as additional layers of defense. Otherwise, the agency can conduct a risk assessment to comprehend which gateway controls could be supplied by method of the application architecture to lessen the gateway control requirements at any gateway layer while watching application.

In this website post, we’ve discussed certain requirements for Australian Government gateways which provide network controls to secure workloads. We’ve outlined the downsides of using traditional on-premises solutions and illustrated how services such as for example AWS Transit Gateway, Elastic Load Balancing, Gateway Load Balancer, and AWS Network Firewall facilitate moving gateway solutions in to the cloud. They are services it is possible to evaluate against your network control requirements. Finally, we reviewed an average web architecture running in the AWS Cloud with associated services to illustrate just how many of the normal gateway controls could be met with a standard Well-Architected approach.

When you have feedback concerning this post, submit comments in the Comments section below. When you have questions concerning this post, take up a new thread using one of the AWS Security or Networking &lt or forums;a href=”https://console.aws.amazon.com/support/home” title=”contact AWS Support” target=”_blank” rel=”noopener noreferrer”>contact AWS Support.

Want more AWS Security how-to content, news, and show announcements? Follow us on Twitter.