NAB reveals third 'evolution' of its public cloud security

NAB is undergoing a third “evolution” in the way it secures public cloud-based workloads, requiring its security teams to come up with an even stronger set of protective controls.

NAB's David West.

The bank revealed to iTnews earlier this month that it is moving towards a software-defined end state for its IT infrastructure, which will encompass multiple public cloud services and on-premises based open hardware.

That multi-cloud architecture, however, requires a fresh uplift to the information security controls that protect NAB’s cloud-based workloads and data.

This effort will officially take the form of a third evolution of NAB’s internal cloud security reference architecture and control framework.

Security strategy and planning manager David West last month offered a detailed look at this framework and the way it has evolved since NAB first started its public cloud journey in 2012.

Speaking at the recent AWS Summit in Sydney, West provided a rare, comprehensive view inside the cloud security operations, strategy and decisions of a major regulated entity.

“As we’ve had to talk to regulators about starting to move some material workloads into the cloud, we’ve found having a framework like this is really useful in terms of communicating very clearly how you do security,” he said.

West said that when NAB put its front-facing websites - such as nab.com.au - into AWS back in 2012, its approach to cloud security - and even cloud in general - was “quite standoff[ish].”

“If I’m honest, we were dragged a little bit into the cloud,” West said.

“There was a lot of animosity towards the cloud.

“But six years ago the cloud was a different beast for security, and some of the key [cloud security] services that we rely on now weren’t available. The platform was very different as well.”

West said that security identified risks associated with cloud and “articulated controls” - which it then passed to the bank’s development teams to implement.

“Where we ended up was we had a very endpoint-centric architecture,” he said.

“We delivered micro-segmentation with security groups, VPCs [virtual private clouds] and NACLs [network access control lists]; we delivered the basis of some of our key controls including logging and monitoring and role-based access control with IAM to a coarse-grain level; and we implemented 2FA for access to the console.”

The second evolution of the bank’s cloud security controls came in 2016, when NAB started to shift transactional workloads into AWS.

This was a major change for NAB’s security division, forcing it to adopt a more active stance.

“We realised as a security team that we really needed to lean in,” West said.

“This cloud thing wasn’t going away and we really had to lean in quite hard.”

West said that the second evolution was characterised by the delivery of some “key foundational security controls” to aid the bank’s expansion into cloud.

“We delivered federated identity, we’re defining identity and access management (IAM) roles and role-based access control (RBAC) policies to a much more granular level, and we’re doing API change detection looking for change and configuration drift across our environment by interrogating the API,” West said.

“We also [started] standardising our account builds and our AMIs [Amazon Machine Images] to the extent that we needed to. We were starting to see a lot more accounts in 2016 than we had in 2012 so as we scaled out it was becoming a lot more difficult to manage, making standardisation much more important.

“And we were encrypting everything: [AWS’ key management service] KMS was now available so we were encrypting [data] at rest and in transit.”

Importantly, the second evolution also led the creation of a dedicated cloud security operations team within NAB for the first time.

“This is the team that’s focused purely on cloud and operating all of the security controls as part of our [cloud security reference architecture and control] framework,” West said.

Two years on, and with the bank now firmly on a path to multi-cloud, the control framework is undergoing a fresh evolution in 2018.

The multi-cloud move coincides with other key architectural decisions, including greater adoption of microservices and APIs, as well as a “cloud-first” approach to newer applications.

“For us as a security practice, it means we’re leaning in even further again,” West said.

“Our cloud security operations team is now evolving to become an engineering team, which means that instead of just monitoring the controls in the cloud, we’re now writing code that is the security controls in the cloud.

“We’re using CI/CD to build-test-deploy that code the same way our developers do. We’re now defining IAM policy and writing config rules; we’re working towards automating everything right the way up to remediation and self-healing; and we’re looking at high-level Amazon services like Lambda to support that as well as Macie and Guard Duty as well in other areas.”

West said the operations team is adopting DevSecOps - often also called SecDevOps - to power its approach to securing cloud-based workloads and data.

This evolution is presently underway.

No longer a ‘blocker’

West sees the bank’s iterative approach to cloud security as an “embodiment” of its broader enterprise security strategy.

He noted it showed the evolution of thinking around cloud, even within a highly regulated industry.

Cloud is an accepted component of IT and one that is allowing organisations to speed up the way they deliver new products and features to market.

Within that context, security can not afford to be seen as a “blocker” to change.

“Security governance shouldn’t be at odds with agility and innovation. In fact we think it should enable agility and innovation,” West said.

“One of the keys to our [broader enterprise] security strategy is keeping the bank safe, ensuring we’ve got the right protections in place to protect the bank and respond to the evolving threat landscape. “We’re also focused on enabling the bank to go faster and to do so safely and securely.

“Our development and technology teams are delivering change at a speed and a cadence that is very different to a couple of years ago, and as a security practice we can’t say no anymore.

“We can’t be blockers and stop this delivery cadence, but we need to work out how can we support the speed at which change is being delivered but do so safely and securely.”

While cloud security postures benefited from specific frameworks and controls, West noted that a lot of traditional security principles still applied in a cloud world.

“The way you solve these challenges is going to be different from an on-prem world,” he said.

He highlighted the importance of taking an iterative approach to building cloud cyber security capabilities, as well as embracing abstraction and automation opportunities presented by cloud-based architectures.

West said the bank’s cloud security focus fell into three main areas: deploying cloud-native security capabilities where it made sense, making cloud-based workloads secure by default (“security should be baked in and not bolted on”), and ensuring cloud security governance is a continuous, iterative process.

“Cloud security governance isn’t a one-off, point in time, set and forget activity, but an ongoing iterative activity that we need to be following and doing,” he said.

NAB’s cloud security governance framework is based around AWS’ shared responsibility model.

Under this, AWS is responsible for the security of the cloud, while the customer - in this case, NAB - is responsible for security of workloads and data running in the cloud.

“That means AWS will take care of the hypervisor down, while you need to take care of the workloads you’re running within AWS,” West said.

“Our governance framework is a layered approach. From the bottom up, we consume all the attestations that AWS provides, whether that’s SOC2, ISO, NIST or whatever that might be.

“We consume those by ingesting them into the cloud security alliance CAIQ [consensus assessments initiative questionnaire] framework to give us a baseline risk and controls view across all of our cloud providers - but in this case across AWS - and we feed that into our internal due diligence and risk management processes.”

The governance framework also involved taking an “atomic” look at every AWS service that the bank consumed.

“Whether that’s EC2, S3,EBS or CloudTrail, we do an atomic risk assessment looking at each of these services before we certify them for production use,” West said.

“We’re looking down that framework to ensure that the right certifications are inherent in those new services  - sometimes the services are ahead of the certifications - but we’re also looking up the stack at our own control environment to ensure that we can integrate these services into the control environment that we’ve built.”

The top layer of the bank’s governance framework outlines the areas in which it is responsible and accountable for its own security in the cloud.

“Finally, last but not least, we wrap end-to-end an ongoing operations and governance framework around that,” West said.

“We’ve got an operations team that are looking at monitoring our workloads very carefully, ensuring that all of the security controls in our framework are operating effectively, and we’ve also got a governance function that are doing continuous ongoing supplier governance, supplier assurance, and service certification.”