A process for threat modeling
As preparation for your threat modeling sessions, you may find it conducive to productive meetings to have the following information prepared:
- High-level architecture of the application
- Solution design documents
- Data models and schemas
- Data flow diagrams
- Domain-specific industry compliance standards
A typical threat modeling process will comprise the following steps:
- Identify the elements in your application that could be targets for potential threats, including data assets, external actors, externally accessible entry points, and infrastructure resources.
- Identify a list of threats for each element identified in step 1. Be sure to focus on threats and not mitigations at this stage.
- For each threat identified in step 2, identify appropriate steps that can be taken to mitigate the threat. This could include encryption of sensitive data assets, apply‐ ing access control to external actors and entry points, and ensuring each resource is granted only the minimum permissions required to perform its operations.
- Finally, assess whether the agreed remediation adequately mitigates the threat or if there is any residual risk that should be addressed.
For a comprehensive threat modeling template, see Appendix C.
Securing the Serverless Supply Chain
Vulnerable and outdated components and supply chain–based attacks are quickly becoming a primary concern for software engineers.
According to supply chain security company Socket, “supply chain attacks rose a whopping 700% in the past year, with over 15,000 recorded attacks.” One example they cite occurred in January 2022, when an open source software maintainer intentionally added mal‐ ware to his own package, which was being downloaded an average of 100 million times per month. A notable casualty was the official AWS SDK.
Who is responsible for protecting against these vulnerabilities and attacks? Serverless compute on AWS Lambda provides you with a clear example of the shared respon‐ sibility model presented earlier in this chapter. It is the responsibility of AWS to keep the software in the runtime and execution environment updated with the latest security patches and performance improvements, and it is the responsibility of the application engineer to secure the function code itself. This includes keeping the libraries used by the function up-to-date.
Given that it is your responsibility as a cloud application developer to secure the code you deliver to the cloud and run in your Lambda functions, what are the attack vectors and threat levels here, and how can you mitigate the related security issues?