10 Tips for Building Compliance by Design into Cloud Architecture
A pair of experts pass along lessons learned while building out the team and processes necessary to support Starbucks' mobile app.
November 5, 2019
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt3a2a75307b055093/64f0d39425b2c65c6427b64c/1.jpeg?width=700&auto=webp&quality=80&disable=upscale)
Among the speakers at last week's (ISC)2 Congress were a pair of security and compliance leaders who helped build out a major cloud project for Starbucks. Matt Wells and Scott Schwan, founders of compliance automation startup Shujinko, were called on by Starbucks several years back to build out the team and processes necessary to support Starbucks' mobile app with fully PCI-compliant and secure cloud architecture measured against standards established by the Center for Internet Security (CIS).
"Basically, in about nine to 12 months, with 20 engineers, we were able to build a highly automated, scalable, repeatable environment that Starbucks could use to back everything they'd want to roll out, and they used that as a foundation to then start moving other applications to the public cloud," explained Wells, who serves as CTO.
Wells and Schwan, CEO, delved into the details of their work at Starbucks to offer the crowd tips on how to bake compliance into their own cloud architecture and scale DevSecOps in the process. We offer the highlights from their insights, in their own words.
"Putting compliance requirements into the definition of done is really important for an engineering team. Many times we don't get into that conversation early enough; we don't talk through it. So the definition of done doesn't include things that are compliance- or security-related. Getting that established for the team is extremely important." --Scott Schwan
"We had a unique situation where we were building an entire cloud platform, and we were responsible for the security of that platform. We were able to set expectations early and basically say, 'Here's the deal: If you want to join this team, you'll get to use some really cool stuff, but you're responsible for security, you're responsible for compliance. If we don't pass our audit, that's on our team -- that's not on the security team or the compliance team.' --Matt Wells
"We made sure that in the beginning we really aligned with security leadership. I do believe in the basic principles of DevSecOps, so if [engineering] teams understand the requirements that they're building to, they can take accountability for what they're doing and that it's no longer security teams swooping in at the tail end of a project and trying to change things or block them or prevent things from going out the door. So part of the culture shift was making sure that we had trust between the teams." --Scott Schwan
"We gathered requirements from the security team, and we gathered compliance requirements from business groups about the geographic areas we had to support. We had all of our [compliance] standards we had to adhere to, which had different requirements. From there we defined procedures. So how are we going to patch servers? How are we going to rotate containers and deploy code?
"We thought it was important to set these procedures before the build-out because as engineers build out [infrastructure], sometimes these procedures will affect the way they build out certain technology. For us, that was kind of the design phase." --Matt Wells
"After design we did a lot of hiring. We needed a lot of really hard skill sets to hire for, so we mixed up the skill sets. We hired a mix of security, dev, and ops [staffers], and what we found was we ended up needing a lot more developers than we did security and operations staff. We were so focused on automation and scale that we found it was easier to bring developers on board and have security and ops sit with them to define how developers were going to build a lot of these capabilities. We didn't go out and hire just straight security professionals. We hired developers to train them to be security professionals." --Matt Wells
"A key tenet for us was automating the hardening of everything we built. The first thing we did is we automated the configuration and hardening of our AWS accounts using Terraform. Instead of spending a day or a couple of hours building an AWS account, setting up logging, password policy, etc., we spent a week and used Terraform to build that out. But in the long run, every time we set up something new in the AWS account, I didn't have to go to my engineers and say, 'Hey, did you set up the password policy?' or, 'Where are the logs going?' I just had to say, 'Did you run the Terraform script to do the hardening? Great. Now we can move on.'" --Matt Wells
"We used a vendor that would scan [new environments] for PCI requirements. So immediately after we ran a script, we ran this and gave them a report. If they still had some issues with PCI, we'd make sure that went back into the sprint, and they added to the infrastructure-as-code in Terraform. And then next time when they set it up, they wouldn't have that red dot from that vendor.
"This was before AWS had some of the tools and services that they have now. Before that we had to build it because that wasn't something that they had in place. We made sure that we incorporated that into the ethos of the team. It was, use the CIS benchmarks, get good feedback, remediate quickly, add it back into your code, and then each time you'd see these things going away." --Scott Schwan
"We always had to verify we were running compliant code, and part of that was through compliance-based testing. We were always making sure that we weren't going to break compliance as we moved as quickly as possible.
"At the end of the build phase, we focused on going through our procedures, making sure what we thought was going to work worked. In most cases they did, but in some cases we had to change our procedures. Most important is that we actually went through and validated our procedures.
"At the end of the build phase, we focused on going through our procedures, making sure what we thought was going to work worked. In most cases they did, but in some cases we had to change our procedures. Most important is that we actually went through and validated our procedures.
Among the speakers at last week's (ISC)2 Congress were a pair of security and compliance leaders who helped build out a major cloud project for Starbucks. Matt Wells and Scott Schwan, founders of compliance automation startup Shujinko, were called on by Starbucks several years back to build out the team and processes necessary to support Starbucks' mobile app with fully PCI-compliant and secure cloud architecture measured against standards established by the Center for Internet Security (CIS).
"Basically, in about nine to 12 months, with 20 engineers, we were able to build a highly automated, scalable, repeatable environment that Starbucks could use to back everything they'd want to roll out, and they used that as a foundation to then start moving other applications to the public cloud," explained Wells, who serves as CTO.
Wells and Schwan, CEO, delved into the details of their work at Starbucks to offer the crowd tips on how to bake compliance into their own cloud architecture and scale DevSecOps in the process. We offer the highlights from their insights, in their own words.
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024