From Abstraction to Implementation, Serverless SRA to
Security Assessment Matrix
We map all domains in the serverless SRA (security reference architecture) into a secu-
rity assessment matrix (SAM). The SAM is the implementation side of the abstract SRA.
Instead of looking at serverless security as domains and areas, we look at it as capabili-
ties. Those capabilities enable us to define the required technology and processes to
secure the serverless application. We first break down the required and critical capabil-
ities under those SRA domains. The more detailed SAM targets the design and imple-
mentation layers, rather than only the abstraction layer.
As an example, looking at the Privilege Management Infrastructure’s Privilege Usage
Management low-level capabilities (Figure 3), we identified the Password Vaulting
capability “applicable” for serverless, and proposed a solution, based on our experience,
industry trends and vendor research.
Password Vaulting is also identified as one of the controls required to overcome the Bro-
ken Authentication threat (that OWASP and PureSec top risk).
Such work is performed across domains and capabilities in the SAM in order to define
the corresponding solution or recommendation to implement serverless security. A sub-
set of the SAM is shown in Figure 6.
Domain High-Level Security Mid-Level Security Low-Level Secu-
rity Capability Serverless
SRM Privilege Management
Infrastructure Privilege Usage
Management Password Vaulting Applicable
SRM Privilege Management
Infrastructure Privilege Usage
Management Privilege Usage
Gateway Applicable
Figure 6: Subset of the SAM, showing the mapping of capabilities and controls
Where the Rubber Meets the Road
Creating a pragmatic, well thought out approach to addressing serverless security will
allow your organization to track changes over time, and build on a foundation where you
have a historical reference point like the SAM. When the question of “why did we do it
this way?” arises, there is a clear capability matrix that gives you an understanding of
the thought process that arrived at the current implementation. So, now that you have
done the modelling, what does the implementation look like?
Let us examine the design patterns we can apply to implement a solution for some of
the top OWASP risks, as shown in Figure 7.
FALL 2019 | THE DOPPLER | 25