Culture comes before technology when focusing on building a secure company – and indeed one that builds secure software – said Amazon Chief Security Officer (CSO) Steven Schmidt forcefully this week.
Schmidt was sharing details about the company’s “Security Guardians” initiative which it uses to “distribute security ownership” across AWS.
“When organizations do have deficient security cultures, the predictable results are repeated attacks against and exploitation of those organizations. Until the security culture changes, the attacks will continue to succeed because without a change in incentives, tooling, behaviors, ownership, and ultimately focus, there will be no material change in actual technical risk management.”
That's the Amazon CSO's view, as he drummed home the point that "quite often people mistake information security (I refuse to say 'cyber' - I think that's too narrow) for a technical problem. It's not. It's a people problem."
Embedded security champions
Sharing a new blog in a series on this "Security Guardians" approach, Schmidt said that "through this program, we train developers to be security champions embedded within their teams.
“This allows us to distribute security expertise and accountability across the organization, enabling us to move fast and innovate while still upholding an extremely high security bar,” he added on LinkedIn.
That blog in question, authored by AWS Principal Solutions Architect Mitch Beaumont and Ana Malhotra notes that “Getting alignment for the need to distribute security expertise starts with deeply understanding what problems need to be addressed. For example”, they posted.
- Is product delivery velocity being negatively impacted by delays in the security review process?
- What business goal or metric are these delays negatively impacting?
- Where in the security review process are those delays occurring?
- What factors are contributing to those delays?
- Is it a lack of time, people, or skills?
A central security programme team supports the process, including with material to teach Security Guardians how to create a threat model.
Positive reinforcement is a key part of the programme’s success, with “mechanisms to continuously surface the great work of our Security Guardians” alongside “awards, gifts, and other incentives” and even a “Guardians Belt Program" from white, yellow, green, through black.
(It’s an approach backed by many other leading CISOs that The Stack has spoken with over the years, with one even more simply highlighting the micro-trophies they developed to reward those best at spotting phishing emails; the lack of awareness of which plagues many organisations.)
See also: Dell's Chief Security Officer on physical security, frameworks, burnout and incident response
Finding creative ways to ensure security is embedded in lines of business at organisations lucky enough to have the scale to do this effectively is a major focus of most. JPMorgan’s Global CISO Pat Opet, for example, told The Stack earlier this year that it was critical that “security engineers are deeply embedded across an organisation’s lines of business and not siloed.”
He pointed to a project at the global bank in which two teams were “building functionally the same thing. One had an embedded security-specific engineer; the other was a team of high performing engineers that didn’t. When it came to delivery, the latter had not thought of “all the failure scenarios that were top of mind from a cybersecurity perspective,” whereas the team with the security engineer had designed for them.
Automation can be your friend here, of course.
“With 35,000+ software engineers, we have to automate the mechanisms by which we deliver requirements and test for compliance" Opet noted at the time. "We spent a number of years kind of building a front door for developers that allows us to profile what they're doing, then gives them the security requirements which are inherited into their backlog. We try and make it as easy and explainable as possible in terms of what you must achieve from a software engineering standpoint – and then on the other side of it, we have built this massive data collection ecosystem, to pull all that data back, centralise it, score it for risk and expose it to [security] teams.
"That becomes an interesting data set for our partners in audit, risk and others."
