Toward the end of the second incident that Volexity worked involving Dark Halo, the actor was observed accessing the e-mail account of a user via OWA. This was unexpected for a few reasons, not least of which was the targeted mailbox was protected by MFA. Logs from the Exchange server showed that the attacker provided username and password authentication like normal but were not challenged for a second factor through Duo. The logs from the Duo authentication server further showed that no attempts had been made to log into the account in question. Volexity was able to confirm that session hijacking was not involved and, through a memory dump of the OWA server, could also confirm that the attacker had presented cookie tied to a Duo MFA session named duo-sid.
Volexity’s investigation into this incident determined the attacker had accessed the Duo integration secret key (akey) from the OWA server. This key then allowed the attacker to derive a pre-computed value to be set in the duo-sid cookie. After successful password authentication, the server evaluated the duo-sid cookie and determined it to be valid. This allowed the attacker with knowledge of a user account and password to then completely bypass the MFA set on the account. It should be noted this is not a vulnerability with the MFA provider and underscores the need to ensure that all secrets associated with key integrations, such as those with an MFA provider, should be changed following a breach.
Again, this is not a Duo vulnerability. From ArsTechnica:
While the MFA provider in this case was Duo, it just as easily could have involved any of its competitors. MFA threat modeling generally doesn’t include a complete system compromise of an OWA server. The level of access the hacker achieved was enough to neuter just about any defense.
FireEye was hacked by — they believe — “a nation with top-tier offensive capabilities”:
During our investigation to date, we have found that the attacker targeted and accessed certain Red Team assessment tools that we use to test our customers’ security. These tools mimic the behavior of many cyber threat actors and enable FireEye to provide essential diagnostic security services to our customers. None of the tools contain zero-day exploits. Consistent with our goal to protect the community, we are proactively releasing methods and means to detect the use of our stolen Red Team tools.
We are not sure if the attacker intends to use our Red Team tools or to publicly disclose them. Nevertheless, out of an abundance of caution, we have developed more than 300 countermeasures for our customers, and the community at large, to use in order to minimize the potential impact of the theft of these tools.
We have seen no evidence to date that any attacker has used the stolen Red Team tools. We, as well as others in the security community, will continue to monitor for any such activity. At this time, we want to ensure that the entire security community is both aware and protected against the attempted use of these Red Team tools. Specifically, here is what we are doing:
We have prepared countermeasures that can detect or block the use of our stolen Red Team tools.
We have implemented countermeasures into our security products.
We are sharing these countermeasures with our colleagues in the security community so that they can update their security tools.
We will continue to share and refine any additional mitigations for the Red Team tools as they become available, both publicly and directly with our security partners.
Consistent with a nation-state cyber-espionage effort, the attacker primarily sought information related to certain government customers. While the attacker was able to access some of our internal systems, at this point in our investigation, we have seen no evidence that the attacker exfiltrated data from our primary systems that store customer information from our incident response or consulting engagements, or the metadata collected by our products in our dynamic threat intelligence systems. If we discover that customer information was taken, we will contact them directly.
From the New York Times:
The hack was the biggest known theft of cybersecurity tools since those of the National Security Agency were purloined in 2016 by a still-unidentified group that calls itself the ShadowBrokers. That group dumped the N.S.A.’s hacking tools online over several months, handing nation-states and hackers the “keys to the digital kingdom,” as one former N.S.A. operator put it. North Korea and Russia ultimately used the N.S.A.’s stolen weaponry in destructive attacks on government agencies, hospitals and the world’s biggest conglomerates - at a cost of more than $10 billion.
The N.S.A.’s tools were most likely more useful than FireEye’s since the U.S. government builds purpose-made digital weapons. FireEye’s Red Team tools are essentially built from malware that the company has seen used in a wide range of attacks.
As you look to manage network security on Amazon Web Services (AWS), there are multiple tools you can use to protect your resources and keep your data safe. Amazon Virtual Private Cloud (Amazon VPC), security groups (SGs), network access control lists (network ACLs), AWS WAF, and the recently launched AWS Network Firewall all offer points of protection for your AWS workload. Managing these security controls directly works well when everything is in a single or small number of accounts. However, if you’re part of a security team managing controls on a larger number of accounts, or part of a compliance team whose responsibility includes auditing and remediating application configurations owned by other teams, managing these controls at scale could become cumbersome. To make sure that it doesn’t become so for you, we’re going to walk you through how to manage the new AWS Network Firewall at scale using AWS Firewall Manager.
First, a primer on the new Network Firewall. Network Firewall is a stateful, managed, network ﬁrewall and intrusion detection and prevention service for traffic in Amazon VPC. With Network Firewall, you can ﬁlter traﬃc going to and coming from an internet gateway, NAT gateway, or over VPN or AWS Direct Connect using both stateful and stateless rules. The network firewall inspects individual packets by using a stateless rule processing engine and inspects packets in the context of their workﬂows by using a stateful rule processing engine. The stateless rules engine takes rules with standard 5-tuple connection criteria. The stateful engine takes rules compatible with Suricata. These capabilities enable you to add more advanced, packet payload–level protections for your VPC resources.
In this post, you will learn how to create, configure, and maintain Network Firewall firewalls with common security policies across appropriate accounts and VPCs in your AWS Organizations structure by leveraging Firewall Manager.
Firewall Manager prerequisites
You must complete the following prerequisites before you create and apply a Firewall Manager policy:
A Firewall Manager administrator account: You must designate one of the AWS accounts in your organization as the Firewall Manager administrator. This gives the account permission to deploy security policies across the organization.
AWS Config: You must enable AWS Config for all of the accounts in your organization so that Firewall Manager can detect newly created resources. To enable AWS Config for all of the accounts in your organization, use the Enable AWS Config template from the StackSets sample templates.
Figure 1 shows an example organizational structure in AWS Organizations, with several organizational units (OUs) that we’ll use in the example policy sets in this blog post.
Figure 1: Best practices OU structure for AWS Organizations
Firewall Manager can be associated to either the AWS primary payer account or one of the member AWS accounts that has appropriate permissions as a delegated administrator. Following the best practices for organizational units, we use a dedicated Security Tooling AWS account (named Security in the diagram) to serve as the Firewall Manager administrator from within the Security OU. The Security OU is used for hosting security-related access and services. The Security OU, its child OUs, and the associated AWS accounts should be owned and managed by your security organization.
This post will focus on two of the accounts in this organization. The first account is the Security Account, since this is where the Firewall Manager Administrator is defined. The second account we will focus on is Tenant 5 in the Staging OU. If you are following these steps, make sure the first account you are signed in to is the Firewall Manager administrator for your organization. You can do this by verifying the Administrator account ID in the Firewall Manager console under Settings. If you don’t have an administrator set, you can find the steps to set one in the Firewall Manager documentation.
Deployment of network firewalls and security policies
Managing security policies begins inside the WAF & Shield console under the AWS Firewall Manager heading. When you navigate from the console and select Firewall Manager, it will bring you to the Getting Started page. You can confirm that you’ve completed the prerequisites mentioned earlier in this post. If the prerequisites aren’t met, use the links in the Prerequisites section to complete the necessary steps. It’s important to note that Network Firewall is the first integration to require the AWS Organizations management account to have AWS RAM enabled. You can find more information about how to do that in the AWS RAM Sharing Your Resources documentation.
AWS Firewall Manager offers multiple security policy types for each service that it manages. A Firewall Manager security policy is a set of configurations that a security administrator defines, including relevant rules, protections, and actions that must be deployed and the accounts and resources (indicated by tags) to include or exclude. With the ability to create a different security policy for each AWS managed service, you can create granular and flexible configurations while still being able to scale control out to large numbers of accounts and VPCs. These policies automatically and consistently enforce the rules you configure even when new accounts and resources are created. For this post, we will focus on the Network Firewall policy type in the Firewall Manager console.
Security policy part 1: Defining a security policy’s rules
The Network Firewall policy type is a regional construct (meaning it applies to one Region only) comprised of stateless rule groups, a policy scope, and policy tags. When you first pick the type of policy in the Firewall Manager security policy console, you also choose the Region you want the policy to apply to. Once you’ve picked your Region, you can configure your policy with a policy name and a Network Firewall policy. This is where you pick the stateless and stateful rule groups and default actions for packets that don’t match any rules, as shown in Figure 2. If you try to add rule groups but none populate the window, this can either mean that you didn’t define any rules and rule groups for the network firewall, or you created them in a different Region. You can choose the link in the window to go to the Network Firewall page to create or import rules.
Additionally, the capacity units for each rule is shown in the interface. Capacity units refer to the total amount of capacity each individual rule allocates towards a total limit for a rule group, and are subject to service quotas. You can find more information on capacity units in the Network Firewall capacity documentation. If you want the same policy to apply to multiple Regions, using AWS CloudFormation StackSets and an infrastructure-as-code approach helps you deploy a policy in each Region. Your CloudFormation template would include the Network Firewall rules, rule group definitions, and security policies.
Figure 2: Defining rule groups for Network Firewall security policy
The next section of the console relates to the configuration of the network firewall. There are two different configuration areas, shown in Figure 3, and once they’re configured they cannot be changed. The first configuration relates to the number of firewall endpoints. This impacts both the cost and availability of the network firewall. Situations where a single network firewall in a single Availability Zone provides adequate availability for the environment could include test or demo environments, applications or workloads that are built solely in a single Availability Zone, or environments where low cost is the driving factor. For environments where high availability is required, applications or workloads are built across multiple Availability Zones, or designers want to reduce cross Availability Zone traffic or dependencies, it’s recommended to use multiple firewall endpoints. To better understand this tradeoff for your workloads, the AWS Well-Architected Framework is the best place to learn more about designing for reliability and cost optimization as well as security, operational excellence, and performance.
The second configuration element is the available Classless Inter-Domain Routing (CIDR) blocks to use for the Network Firewall subnets when they are being created. This optional field should have the /28 subnet you intend to have pulled from the VPC CIDR block as part of the creation of the network firewall. This comes in handy if VPCs in an organizational account follow consistent IP addressing practices, and it will allow more intuitive design guidelines and implementations. You can find more information on how the CIDR blocks are used in the Firewall Manager documentation for security policies. If this field is left blank, Firewall Manager will take a best-effort approach to find unassigned CIDR blocks in your VPCs to create a subnet for Network Firewall. If no CIDR blocks are available, Firewall Manager will display a non-compliant error on its dashboard.
At this point, you’ve defined the Network Firewall security policy’s rules; the next step is to define what the policy should apply to.
Security policy part 2: Defining the security policy scope
Now that you’ve defined the security policy rules, the policy should be scoped to apply only to the appropriate accounts and VPCs. It’s important to note that for each security policy, there will be one Network Firewall instantiation. Therefore, if you apply multiple security policies to an account or to a VPC, multiple firewalls will be created, leading to inefficient routing, cost, and complexity. Firewall Manager doesn’t merge proposed configurations into network firewalls created outside the Firewall Manager framework. Firewall Manager can, however, update or change the configuration of firewalls it manages at any time. Therefore, it’s best to architect your policies with your organizational structure in mind.
Firewall Manager enables you to modify all accounts and resources in an organization, or tailor a policy scope to specific OUs and resources. The architecture diagram in this blog post outlined a practical scenario for how you can structure OUs. Considering security policies, it would be reasonable for network firewalls to have different policies in a Production OU that impacts Tenants 1 and 2, compared to the Sandbox OU for Tenants 7 and 8. However, you might have some commonality between the Pre-prod and Staging OUs. So, for example, you might want to apply the same Network Firewall rules groups across an organization, as shown in Figure 4.
Figure 4: Applying rule groups to an AWS Organizations OU structure
To do this, you would create three different Firewall Manager security policies inside the Security Account in the Security OU:
Prod Environment Policy
Contains rule group “Block-Known-Bad-IPs” and “Block-BadDNS”
Applies to Prod OU
Dev Environment Policy
Contains rule group “Block-Known-Bad-IPs” and “Block-Corporate-Prod”
Applies to Pre-prod OU and Staging OU
Sandbox Environment Policy
Contains rule group “Block-Known-Bad-IPs”
Applies to Sandbox OU
This policy application is shown in Figure 5.
Figure 5: The corresponding security policy application
In addition to applying the security policy to accounts in OUs, it is also possible to filter based on the tags associated with VPCs in the accounts, as shown in Figure 6. For example, if your accounts contain a VPC with bastion hosts, enforcing the same routing and outbound traffic policies could break other security elements. In these cases, tagging the VPC with a consistent identifying key pair such as “Bastion-VPC:True” would enable Firewall Manager to exclude that subnet from requiring a path through the network firewall.
Figure 6: Defining the security policy scope by organization unit and tagging
Security policy part 3: Defining the security policy tags
As part of your Firewall Manager security policy, you should also define policy tags. These tags can be used for multiple purposes, including adding context, defining ownership, or even authorizing changes by using attribute-based authentication with IAM. This step is optional, but recommended to improve the operations. Some recommended tags include:
Policy description: A longer description to capture the purpose of the policy
Policy owner: A contact person for when changes to the policy must be made
Cost Center: Where costs associated with the security policies should be incurred
Last date edited: Enables you to keep track of changes to the policy and map the changes back to a change log or ticketing system
Last date reviewed: Helps maintain an audit schedule to verify that appropriate policy is set and audits mandated by compliance regimes are easily captured
Your organization might have other tags that are also mandated, and these can be configured upon policy creation as well.
Once you’ve defined the appropriate tags, you can review the policy before Firewall Manager puts your policy into effect. It’s important to also note that when you choose Create Policy, Firewall Manager creates AWS RAM configurations and AWS Config rules to enable management and visibility for the Firewall Manager Administrator account, and the member accounts will incur the associated costs.
After the Network Firewall deployment
Now the Firewall Manager policy has been created. On the AWS Firewall Manager policies screen, shown in Figure 7, you’ll see the total number of accounts that are encompassed by the OU selection and tag filters you created, and the number of accounts that are fully compliant with the policy. Because this is a new policy, Firewall Manager must evaluate the status of the accounts before deeming them compliant or noncompliant. Another benefit of this view is the ability to report on ongoing compliance with any given policy. Remember how AWS Config is a prerequisite for Firewall Manager? That’s because AWS Config enables Firewall Manager to access information about the current state of the firewalls and VPCs in each account and report back and/or enforce compliance with the policy on an ongoing basis.
Figure 7: Validating compliance of accounts by policy
In the background, Firewall Manager is building the components required for the network firewalls in each account. This includes the dedicated firewall subnet, the associated route tables in each specific VPC, and then the firewall itself. Once these tasks are completed, Firewall Manager pushes the rule groups defined in the security policy. If a network firewall already exists, Firewall Manager will still follow the same steps and create additional subnets, route tables, and firewalls in the VPCs. Remember, as we mentioned earlier, that Firewall Manager doesn’t update or change the configuration for network firewalls it didn’t create.
Once the resources are built, it can take a couple of minutes for the accounts to be evaluated and appropriately classified in the Firewall Manager console. After the accounts have been evaluated, selecting the name of the Firewall Manager security policy shows which accounts are within the policy scope, their status, and any relevant details. If Firewall Manager identifies any noncompliant events, statuses, or policies, this area of the console is also where those alerts will appear. For a detailed list of possible event types, the Firewall Manager documentation can provide more information.
If you look under Policy Action there is an important informational box, shown in Figure 8.
Figure 8: Information box that identifies necessary route table update actions
Firewall Manager creates the network firewall in the defined accounts, but it doesn’t automatically modify the route tables inside the VPC. This ensures that changes being made by the central security team don’t impact other activities that may be going on in the accounts. Consider a situation where the account is owned by the DevOps team and security is owned by the central Security team. This situation makes it possible for the Security team to roll out the new network firewall without impacting the network path of the application. Once the firewall is deployed, the Security team can engage the DevOps team to push the routes into production through the appropriate code pipeline. Steps to modify the route tables can be found in the blog post that covers the deployment models for AWS Network Firewall.
In this blog post, you learned how security administrators can use Firewall Manager to create security policies for the new Network Firewall service and push them out at scale to their organization. As part of that walkthrough, you also learned how compliance auditors can use Firewall Manager to see, in a single place, the compliance of each account with that policy. In the end, by having AWS do the undifferentiated heavy lifting of deploying resources and collecting state at scale, security teams can focus less on operational burdens and more on strategic opportunities. For further reading and updates, see the Firewall Manager Developer Guide. To learn about pricing for solutions using AWS Firewall Manager, check the AWS Firewall Manager pricing page for examples.
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.
The collective thoughts of the interwebz
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.