How to Build Security Culture in Agile Cloud Teams

TL;DR

Make security fast, automated, scalable, and directly accessible to developers so agile product teams can deploy safely without waiting weeks for infrastructure. Xero supported this approach by treating security systems as code, following the AWS Well-Architected Framework, sharing responsibility, protecting every layer, and aligning the security team’s operating pace with development teams and cloud-service changes.

Transcript

Hi, everyone. Good afternoon. My name is Aaron Jones. I am the room facilitator for RSA. Uh, this afternoon's session is the Automated, Continuous, Invisible and Building a Solid Security Culture at Speed. Our speaker this afternoon is Aaron McEwan, Head of Security Engineering and Architecture at Xero. Without further ado, Aaron. There she is. Tha... Read More

Key Insights

• Developer-accessible security is essential in an agile environment because product teams need to initiate security components without waiting for a separate team. Xero made developer initiation a central goal of its automated security stack, helping security practices become part of normal engineering work.
• Cloud migration can improve both delivery speed and security when infrastructure is automated. Xero sought to reduce infrastructure build times, including security infrastructure, from weeks to minutes, seconds, and milliseconds while maintaining and improving the organization’s overall security posture.
• The AWS Well-Architected Framework guided Xero’s security architecture through defense in depth. Protection was applied at multiple layers, including the edge, perimeter, hosts, data in transit, and data at rest, rather than relying on one protective boundary.
• Shared responsibility allows an organization to focus on securing its own systems while using the capabilities of security partners and its cloud provider. Xero divided responsibility among its internal organization, external security partners, and Amazon Web Services as part of its architecture.
• Account isolation and segmentation supported Xero’s product-team model. The organization deliberately used more than 102 AWS accounts and many AWS services, allowing numerous autonomous teams to operate while establishing separation between their environments as part of the architecture.
• Security teams must operate at the pace of development teams and cloud providers. Xero’s security function adopted accelerated execution because its product teams moved quickly and Amazon Web Services introduced many new features, creating an ongoing challenge for security specialists.
• Security systems should be treated as code to make their deployment and management repeatable. Xero’s principles called for continuous integration, continuous deployment, auto-scaling, and API-driven infrastructure instead of relying on static security systems or slow manual provisioning.
• Security culture can emerge through communication and conflict between security specialists and autonomous product teams. Xero’s many teams created numerous stakeholders, communication paths, and disagreements, but those conversations also helped develop stronger security awareness across the organization.

Questions & Answers

Q: How can an agile company make security accessible to developers?

An agile company can make security accessible by building automated components that developers can initiate themselves. Xero made developer initiation a personal goal of its cloud security architecture because its product teams needed to move quickly. Treating security systems as code, deploying them through continuous integration and continuous deployment, and driving infrastructure through APIs reduced dependence on slow, manually provisioned systems.

Q: What security goals guided Xero’s migration to AWS?

Xero established two explicit security goals for its migration to Amazon Web Services. The first was to prevent accidental information disclosures. The second was to build infrastructure and systems that support internationally recognized security standards. The security architecture was also intended to maintain and improve security while helping the business grow and dramatically reducing the time required to build infrastructure.

Q: How did the AWS Well-Architected Framework shape Xero’s security architecture?

The AWS Well-Architected Framework supplied design principles for a comprehensive security architecture. Xero applied security across multiple layers through defense in depth, protecting the edge, perimeter, hosts, data in transit, and data at rest. The framework also reinforced shared responsibility, with security duties distributed among Xero, its security partners, and Amazon Web Services rather than assigned to one party alone.

Q: Why should cloud security systems be treated as code?

Treating security systems as code makes their construction and management repeatable and automated. Xero connected this principle to continuous integration and continuous deployment, Amazon Web Services auto-scaling, and API-driven infrastructure. The approach replaced static infrastructure and supported the broader goal of reducing security infrastructure build times from weeks to minutes, seconds, and milliseconds while operating at greater scale.

Q: Why must security teams operate at an accelerated pace?

Security teams must execute quickly because the development teams and cloud platforms around them also change quickly. Xero’s autonomous product teams selected technologies and delivered at an agile pace, while Amazon Web Services released a large number of new features. A slower security function would struggle to keep up, so Xero made accelerated operation a central security engineering principle.

Q: How did Xero organize AWS accounts for agile product teams?

Xero used an architecture based on isolation and segmentation, with many AWS accounts assigned by design to support product-based teams. At the time described, the company had more than 102 AWS accounts and used many AWS services. This structure matched an organization containing hundreds of product teams, commonly arranged in pods of six to eight people with significant technology autonomy.

Q: How can conflict contribute to a stronger security culture?

Conflict can create the conversations through which product teams develop security awareness. Xero’s hundreds of autonomous teams produced many stakeholders, communication paths, and competing priorities. The security leader noted that discussions arising from those conflicts could begin building security culture inside the organization. Security influence therefore depended partly on continued engagement with teams rather than direct authority over their decisions.

Q: What principles supported Xero’s cloud security practice?

Xero’s stated security engineering principles included the repeatable and automated building and management of security systems, operating at an accelerated pace, and providing on-demand security infrastructure that works at any scale. These principles reflected the needs of a rapidly growing platform whose usage rises and falls, as well as product teams that require fast access to secure infrastructure.

Summary & Key Takeaways

• Xero completed a three-year migration from on-premise infrastructure to Amazon Web Services in November 2017. The migration moved more than 1.4 petabytes of data and thousands of servers. Its security goals included preventing accidental information disclosures and supporting internationally recognized security standards while preparing the business for further growth.

• The security architecture followed the AWS Well-Architected Framework, applying defense in depth across the edge, perimeter, hosts, data in transit, and data at rest. Xero also adopted shared responsibility, dividing security responsibilities among its internal organization, security partners, and Amazon Web Services while concentrating on securing systems within its control.

• Xero’s agile, product-based teams operate in small pods and can select their preferred tools and technologies. Security therefore had to become an enabling product function rather than a blocker. Its principles emphasized repeatable automated deployments, accelerated execution, and on-demand infrastructure capable of scaling with fluctuating platform usage.