How Commonwealth Bank simplified the compliance journey

Eric: Good evening, everyone. Thanks for coming out to our late session tonight on cloud compliance. We're going to talk to you about the journey to compliance in the cloud and share a use case from Commonwealth Bank.

My name is Eric Westfall. I'm a Principal Technologist for Security Compliance at AWS. I'll let Roven introduce herself.

Roven: Hi everyone. My name is Roven. I'm a Principal Technologist based in Sydney.

We also have a third speaker, Artem from Commonwealth Bank, who couldn't join us today but recorded a video to talk about their compliance journey.

Eric: Thanks Roven. To recap how we'll go through this:

I'll speak about what we're seeing across the industry regarding compliance in regulated industries like financial services. We'll go through some compliance challenges, talk about achieving continuous compliance assurance in AWS, and then walk through Commonwealth Bank's journey. Finally, we'll share some helpful resources relevant to this use case.

But first, let's talk about why compliance matters in the context of cloud operations - why it's a cloud ops problem, not just a security problem.

With cloud operations, it's about setting up a well-architected environment to run workloads securely and efficiently at scale, while optimizing costs. Security and compliance fit into the setup and operate phases - things like establishing a secure landing zone, configuring AWS services like Security Hub and Config, and automating remediation of non-compliant resources.

There's a strong cloud ops story here with the optimizations, automation, and integrations between AWS services.

So in the context of a cloud ops model, how does continuous compliance fit in? We think it spans all stages, but primarily setup and operate, whether that's configuring foundational security controls or operating at scale with automation.

Let's look at what we're seeing in financial services regarding security and risk challenges:

  • Evolving regulatory requirements
  • Highly dynamic security threat landscape
  • Stringent reporting and documentation requirements

The threat landscape data from 2022 shows some worrying trends:

  • 35% increase in ransomware attacks targeting regulated workloads
  • 77% increase in phishing attacks targeting financial services
  • 27% of incidents had confirmed data disclosure, 18% had potential data disclosure
  • 58% of denial of service attacks were part of larger, multi-stage attacks

This shows we need to focus on protecting data - the crown jewels - with strong controls across infrastructure and at data boundaries.

So how do we approach cloud compliance assurance? The three lines of defense - manage risk, oversee risk, and provide assurance. We'll talk about AWS services like Config, CloudTrail, Systems Manager, and Security Hub to achieve this.

Roven will now get into the details.

Roven: Thanks Eric. As Eric mentioned, the first line of defense is to manage risk using preventative and detective controls.

Preventative controls aim to prevent issues proactively. Detective controls detect issues after resources are created.

Preventative controls involve risk assessment to identify vulnerabilities, and then protection/prevention actions if risks are unacceptable.

Detective controls involve threat detection through monitoring logs and metrics to identify unusual behavior, and then incident response to mitigate threats.

Here we've mapped AWS security services to preventative and detective controls across categories like identity, infrastructure, and data protection.

Let's see how Commonwealth Bank started their compliance journey using detective controls. I'll hand it over to Artem to explain.

Artem: Hi everyone, I lead the Cloud Controls team at Commonwealth Bank of Australia. Let me walk through how AWS has allowed us to transform cloud governance and compliance, delivering better outcomes for our application teams.

Commonwealth Bank is the largest bank in Australia with almost 7 million active customers. A key goal is extending our digital leadership through new products and experiences, and public cloud plays a big part in that.

With many workloads running and an accelerating journey, it's even more important to govern and secure the cloud at scale and exceed expectations.

The most significant shift came from business and application teams wanting self-service access to cloud services. This created two problems to solve:

  1. How do we accelerate the journey safely?

  2. How do we create a compliant monitoring solution for the new self-service model?

It wasn't just a technology problem. We had to transform processes and culture to balance innovation and agility with accountability.

Our existing governance methods were like having speed limits, speed humps, and driving instructors in every car. We needed less invasive methods like random speed checks and cameras.

Just as technology evolved to create speed cameras for roads, we could do the same in the cloud - a "trust but verify" approach.

So we gave teams direct cloud access with some basic controls, then used cloud introspection capabilities to create a detective control framework called Curator to inspect usage in real-time for policy compliance.

We chose AWS Config rules and Conformance Packs because of the integration across AWS services, real-time visibility through reporting dashboards, and ability to provide data-driven checks.

This increased accountability - a cultural shift for teams to go through. Curator was built using various technologies like Config, Lambda, DynamoDB, and data lakes on S3.

It gave us real-time visibility and confidence in controls with clear remediation actions. And by making non-compliance visible immediately, we shortened the feedback loop for teams to self-correct frequently.

But we had challenges with custom Config rules requiring lots of manual effort, and scalability across our 500 accounts.

This is where we engaged AWS to evolve Curator using native AWS services like Config Managed Rules and Conformance Packs to address those speed and scale challenges.

Eric: Thanks Artem. When we first got engaged to evolve Curator, we assessed how it was built and the challenges.

We realized we could leverage AWS Config, specifically managed rules and conformance packs, to address many of the challenges while still using the AWS services Commonwealth Bank had already adopted.

AWS Config continuously monitors resources, recording configurations and changes over time. It can assess resources against desired configurations and generate compliance reports.

The key value propositions are:

  1. Configuration change management - track changes across accounts

  2. Compliance assurance - evaluate resources against compliance standards

  3. Security analysis - analyze resource relationships and configurations

Config integrates across AWS, enabling continuous compliance at cloud speed and scale. Conformance Packs provide curated, pre-defined rules aligned to common compliance standards, best practices, and internal policies.

Managed Rules require no rule writing or maintenance, and are created by AWS security experts. They automatically stay up-to-date with the latest guidelines.

This enabled Commonwealth Bank to establish preventative and detective controls across workloads at scale, creating guardrails to empower teams with agility and autonomy within a secure environment.

Roven: Thanks Eric. Now let's see how Commonwealth Bank leveraged Config Managed Rules and Conformance Packs to advance their compliance program.

Artem: To leverage the benefits of Config, we first created a centralized rules management framework.

This allowed us to govern rules across all accounts from a central Config Aggregator, while distributing rules to each account and region for automated compliance checks.

We started with critical foundational security controls like encryption, access management, and network security using Managed Rules. This gave us 80% coverage of key controls through pre-built rules maintained by AWS.

For more nuanced internal policies and industry standards, we used Conformance Packs. This gave us 20% extra coverage aligned to standards like PCI DSS.

The biggest benefit was lowering the effort to create and maintain rules by over 90% compared to our custom rules. This freed up our engineers to focus on higher value activities.

With Config Aggregator centrally aggregating data, we gained visibility into the compliance state across our footprint through dashboards and reports. We could identify accounts and resources needing remediation and track trends.

Finally, we integrated Config with our existing AWS Lambda remediation functions, so resources automatically self-remediate if they drift from compliance.

The outcome was a scalable, extensible, and automated compliance framework to securely progress our cloud journey. We reduced compliance effort and risk, while enabling innovation and agility across the bank.

Eric: Thank you Artem for sharing Commonwealth Bank's journey. Let's recap some key takeaways:

  • Achieving continuous compliance requires managing risk across preventative and detective controls

  • Leverage AWS native services like Config and Security Hub to establish controls across accounts and resources

  • Start with critical foundational security controls, then expand coverage to industry standards

  • Reduce compliance effort by 90% using Config Managed Rules and Conformance Packs

  • Centralize rules and aggregate data for visibility into compliance state

  • Enable self-remediation to automatically correct non-compliant resources

We've shared some resources that dive deeper into these services and patterns. Please reach out if you have any other questions!

The second thing is compliance because you can use AWS Config to implement compliance across all of your organization. And the third one practically is the visibility because once you enable Config and you get these compliance reports across all of your accounts in the organization and change management, you can aggregate all of this into, into one management account or one centralized account and you see all of this in one plane of glass practically.

So let's talk about the main um features of Config. The first one is advanced query. Advanced query provides a single query end point where it gets the current resource metadata without performing any specific service API request. And then it's allow you to also use Config, uh AWS Configuration, uh aggregator to run these queries against all of the accounts in one centralized management account if you'd like.

The second uh key feature is Conformance Packs and Conformance Pack is a collection of AWS Config managed rules or custom rules and remediation actions that can be easily deployed as a single entity across set of accounts or the entire accounts in your organization. And one of the key value proposition for Conformance Pack is when you deploy a rule, this rule is immutable so it cannot be changed by anybody in any of these linked account, even admins.

The third key feature I wanna mention is uh automated remediation. So you can use AWS Config to automate the remediation for non compliant resources based on recommended uh actions. And this is a great segue for compliance as code, right? So compliance code is a critical for scalability. You don't want to do any manual evaluation or creating things, especially when you manage hundreds of accounts, it becomes unsalable and undoable as a matter of fact.

So let's have a look into how can we implement compliance at a scale. First, we have AWS Config that will continuously evaluate AWS resources configuration for the desired settings we want and it capture resource configuration snapshot. Once Config records, it's normalize the changes into a consistent format and deliver it to your S3 bucket. And this change uh records and also uh files are accessed by Config console and also APIs. So you see you see them in the console or through APIs, you also have the option to get notified by SNS topic.

Had any changes been made depend on the rules that you use in. Config Config will do evaluation based on a set time if you use bureaucratic rules or it will do the evaluation based on a change if you, you or what's known as trigger based rules. So each role is associated with Lambda which contains the logic or the evaluation logic of the rule. When Config evaluates the resources, it invokes the rules, Lambda which she checks the uh status of the resources. If it's compliant or not, then it reports its compliance status in Config console. If it's not compliant, meaning that the resource not or or violate the rule uh configuration, it will flag it as non compliant resource in Config.

And with that, let's have a look how Commonwealth Bank picked up compliance as a code concept and implemented into their environment. So back to Artem Bednarchuk, as Raven explained how to codify compliance, it was critical in CBA to adopt compliance as a code to be able to speed up deployment at our scale of 500 accounts. So we don't need to implement controls an account by account, we can deploy them at once. So we use CBA GitHub to manage all controls settings and custom rules. And we integrated these a BS C I CD services like CodePipeline, CodeCommit and CodeBuild to deploy these controls in the a BS Config for each account and to also use S3 to store artifacts.

So let's talk about remediations, how we manage remediation process. In CBA, our application team reviews the compliance alert through the dashboard on a regular basis. And if there is new alert, they have to add it into remediation, register for this team review. Our risk team also provides remediation playbooks for common findings which can be actions or remediated by using Lambda. So we keep all artifacts for holding in S3. The artifacts are there to tell us to know what was the a lot action taken and how it was fixed.

So this is was for our application team for our centralized security ops who looks after cloud security across all accounts. We need you to aggregate all these alerts in one place through Config aggregator which is resource type that collect a based config configuration and compliance data from multiple a based accounts and region into one single account to get centralized view of all resources, inventory and compliance status. For that analysis. We use advanced query which provides a single query functionality and end point to get current resource state meta data. So we can use it for to perform hot queries against a b resources such as viewing all Amazon S3 buckets that have versioning disabled svhg speed and scalability, the work of the bs to optimize these services.

Great. So throughout our engagement with the bank, they have requested a couple of product feature requests to enhance the service. Things like integrating AWS Conflict findings with Security Hub. So Security find the the findings from um Config can be injected into Security Hub and the Security Hubs team don't have to jump between two dashboard of Config and Security Hub.

The other thing is the ability to create custom rules in Conformers Bank. So when Conformers Pack first got released, it only supported managed rules and that's one of the product feature requests the bank have requested as well. The other thing based on their scalability, they are the largest bank in Australia, they needed to have a larger number of rules per account per region. And that was another product feature request they asked to implement.

And we got all of these product feature request and went back to our product team and we told them about the use case and the need for this feature requests. And surely enough as always, the project team listened to the feedback from the customers and went and released all of these uh feature requests.

Another thing was cost as any bank or any customer who cares about compliance and security leveraging services like AWS Config is one of the key cornerstones into compliance journey. So they came to us and say we would love to continue to use and use more, but we would like you also to review its pricing and we passed on these feedback to our service team as well. Who if you haven't heard just released, spent this year a reduction of 58% of Conformance Pack price.

On a different note, when we were going through a review of the uh compliance framework, we realized that the bank use bureaucratic rules on an hourly basis, which is quite aggressive. So we dig deeper into the use case of this to try to understand is that because of an auditor request, for example, they need to run this evaluation every single hour or because of what? And after a couple of conversations, evaluating the use case, we ended up moving them to trigger based rules. So they saved up to 40% of the cost of their evaluations.

All right. So overall, we looked into how did we address the challenges that the bank had with the first compliance framework that they created correa because they had a clear challenges with it. And by implementing AWS Conflict managed rules and Conformance Packs, has these pains gone or not? And what benefit did the bank gain?

So the first benefit that the bank uh had was the deployment force. So now we embedded continuous and automated detection of end remediation of compliance violation directly into their C I CD pipeline. The other thing as well is the visibility and reporting. So now the risk theme and security ops able to get a view, a real time view for their compliance status across all of the accounts, regardless of the region at their fingertips without going and hassling the application teams.

And speaking of visibility and reports gonna mention aggregation because they're using, as you heard Art saying over 500 accounts. So going through a report across this, many accounts could be exhausting. So aggregating this report across the entire organization was one of also the key benefits that they gained out of there.

The other thing is uh the point is reducing the engineering time. So if you heard Artem talking about their engineering team used to create custom rules and do the evaluation and that was taking a lot of time and effort from their side to be able to create this rule tested and then uh see the evaluation. So practically using the managed rules of Config have reduced this time significantly. And that was a significant benefit because now they can focus their efforts on something else when it comes to security.

The other thing is Conformance Pack, immutable rules as any customer who has auditors add their back or have certain security benchmark, having immutable rules is a peace of mind when you deploy a rule. And you know, for a fact that there is no one in your organization, even with an admin access can change this rule and it's quite powerful.

So with that, we've addressed the pains or the challenges Commonwealth Bank had with correa and we also define a new set of compliance framework that they gained out of it when it comes to speed and scalability. But we didn't stop there after implementation of Conflict and Conformist ma we wanted to continue on that joint journey between AWS and the bank to uplift the security and capabilities of uh of the security posture.

So we looked into what else can we do from a detective control perspective that enhance their visibility and get them to respond to any issue without having an impact on their system. And when we looked into the detective controls and i did show this uh part of the slide earlier we looked into, ok, it's maybe time to look into threat detection and implement GuardDuty.

So let's check it out. So GuardDuty is a threat detection service on AWS. It continuously analyze AWS sources to produce finding based on a threat that has been identified. We identify rate around different resources. So your Amazon S3, for example, the object that you have there containers workload, it could be EC2 and also the actual accounts and users GuardDuty works on a different data source by default things like VPC flow logs, uh DNS query and also CloudTrail uh CLA CLA events.

And it produce findings in a category from low to medium to high. So it's easier for you to know which one you need to action, the findings that uh GuardDuty produce. You can consume it from the console or also through uh APIs. And you can also use EventBridge as well to consume these uh these findings. And if you do have an ITSM uh tool, you can use it. And in integrate that with Config to feed in these finding into your ITSM whether it's Jor ServiceNow or, or else you can actually inject these finding in your ITSM uh tool and you will uh and tag certain teams to uh change the compliant of certain risk.

All right. So all of this really focused to give you the right information. So you can make informative decision on how you're gonna mitigate these threats. So let's talk about or have a deeper inside how the GuardDuty workflow works.

So we mentioned before GuardDuty works on different uh it's actually five different uh set of data or data source, which is things like VPC logs, CloudTrail events and DNS queries. It also looking to add bands query from AWS. So things like DNS query host CloudTrail events, S3 data plane events and EKS control plane, all of these data sources automatically and continuously injected into GuardDuty.

So you don't really need to turn on anything. It's automatically get done in the background once you enable uh GuardDuty, which is quite great. And regardless of your scalability, whether you use one ECS cluster, for example, or 100 it doesn't matter, all of these logs will be injected automatically.

So G duty will gonna produce different kind of detections. One focus on threat intelligence. So we get the threat intelligence from two of our partners, which is CrowdStrike and ProofPoint as well as AWS threat intelligence generated by our internal AWS team and used internally with an AWS and Amazon platform. So you're able to detect on these um threat intelligence, things like bitcoin mining or any communication to bad known servers.

Another thing as well is detecting anomaly and this is where GuardDuty use machine learning in back in the background to learn about the normal operation was in your account. What is the normal pattern look like? And then it will start detect anomalies and notify you. If there is anything an example of that would be if there is a large amount of object from S3 gut retrieved, which you usually don't retrieve this number of files on a regular basis.

We did mention before it does actually categorize the findings into categories. So it's easier for you to uh execute them into high, medium and low. And if you do have or if you do use uh AWS Security Hub, it's automatically flows these finding into Security Hub dashboards.

So let's talk more about Security Hub. So from security monitoring and detection, Commonwealth Bank use a set of a S security services or native security services from AWS, things like GuardDuty for threat detection, Macy for three inspected, inspect EC2 and S for any vulnerabilities. And also IAM Access Analyzer to analyze the access pattern and see what doesn't make sense. And they obviously use Config AWS Config and Conformance Pack for compliance.

And then they started to use Security Hub and aggregate all of these security finding from all of the services that I've mentioned into the dashboard of Security Hub. So the security ops team don't need to jump across all of the services dashboards and finding to find out what is happening. They just go to Security Hub and they will be able to know exactly what happened across the board in all of the accounts and finding that each of these services have uh have, have triggered and then the they can also take actions.

All right. So here's a simple uh Security Hub aggregator, uh dashboard, by the way, so you can uh see the region, you can also add or subscribe regions, you can see the category over there uh that got uh identified from critical, low, medium, uh and critical, high, sorry, critical, high, medium low. And then here is the dashboard for the finding itself.

So Security Hub consumes and aggregate, then prioritize the finding from all of the AWS native security service and, and this is really great. It also aggregate and able to inject finding from third party partners. So if you use partners for security, like for example, um antivirus or things like that, I'm not gonna mention name, but you can actually, if you find this vendor or this partner supported by Security Hub, you can inject the security findings and have it as well in the same dashboard.

So the Security Hub finding includes things like the severity of the finding itself, the region, the product nature and also the resource id. So you know exactly what you need to do, ah and what to trigger when it comes to remediation.

So let's see how Commonwealth Bank leverage bose GuardDuty for threat detection and Security Help to aggregate all of these findings within their environment to uplift detective controls and security posture.

So back to Artem Bednarchuk, they manage the remediation process for the Security Hub findings by getting our application team to review the alerts. If there is new alert, they add into remediation register and get reviewed by re team and check against existing playbooks.

Each alert has a couple of statuses, new notified suppress result to help each team understand which alert they need to attend to. For example, suppress means it can be improved exemption by cops. Then we built what we called finding workflow using API calls to Security Hub to update finding status at scale.

So let's talk more about finding workflow. They used to have a specialist who used to review each a lot and change its status based on the remediation register. There's a number of findings they got, they need to change this manual process by implementing finding workflow, which we consider to be a self service framework where each application team has their own portfolio and cloud control github repo we use yamo file to simplify finding status.

All application teams needs to do is to specify account details, role name and finding status. Then in the background at the base code pipeline, the start box flow for the team based on the details in the yama file. This ks framework help us to improve the liability, visibility, updating and action, all this finding at scale.

So let's talk more about a lot remediation Security Hub automatically sends all the new findings and updates all the existing findings to EventBridge as an event. They written simple rules to indicate which event could be an interest for us and that action to and what action to take when the event makes a rule.

The main action we use that automatic trigger invoke a BS lambda invoking Amazon Easy to run command, notify Amazon S ms topic or Amazon SKSQ a sending findings to ITSM tools. There are second figure and then be rules to respond to those events.

All right. So to wrap up practically Commonwealth Bank constantly looking for ways to transform governance mechanism using the latest capabilities of AWS in c balancing the compliance and enablement to practically reduce friction. They also leverage or use compliance as a code to speed up deployment, which was a critical aspect for their scalability.

Another thing is leveraging uh AWS Config specially managed rules and Conformist Packs. And I got to point out the immutable rules of Conformers Pack because that was a game changer and peace of mind for their security team.

Another thing is reducing the time that was required by the engineers to do all of these heavy lifting of creating rules and doing the evaluation by using native AWS service to do all of this work and aggregate all of these finding for them.

So I hope this has given you some insights into how Commonwealth Bank of Australia have went through their compliant journey and what services have they leveraged and what pain they already started with and then shifted to a benefit later on.

I've got a couple of resources here for you that might be beneficial to get you started on your own compliant journey. So all of these are AWS resources that can help you either start your compliance as a code or help you using uh some of the samples we have in our GitHub repositories.

I also want to point out our AWS Cloud Operation booth at the I think exo so if you have any questions about cloud operations and AWS or security and compliance, feel free to pop in there. There were plenty of AWS folks that will help answer your questions.

And with that, I hope the section has been informative for you and you got some insight from another customer that we have who use AWS services to achieve compliance at a scale. Thanks everybody.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值