我的书签
添加书签
移除书签- Objective
- Collect information on the building blocks
- Collect information on relations between building blocks
- Use collected information in secure software development practices
Introduction
Context
During securing applications based on microservices architecture, security architects/engineers usually face with the following questions (mostly referenced in the OWASP Application Security Verification Standard Project under the section ):
- Threat modeling and enforcement of the principle of least privilege:
- What scopes or API keys does microservice minimally need to access other microservice APIs?
- What grants does microservice minimally need to access database or message queue?
- Data leakage analysis:
- What storages or message queues do contain sensitive data?
- Does microservice read/write date from/to specific database or message queue?
- What microservices are invoked by dedicated microservice? What data is passed between microservices?
- Attack surface analysis:
- What microservices endpoints need to be tested during security testing?
In most cases, existing application architecture documentation is not suitable to answer those questions. Next sections propose what architecture security-specific information can be collected to answer the questions above.
Objective
The objectives of the cheat sheet are to explain what architecture security-specific information can be collected to answer the questions above and provide concrete proposal of approach to collect microservice-based architecture information to securing application.
Proposition
Application-functionality services implement one or several business process or functionality (e.g., storing customer details, storing and displaying product catalog). Collect information on the parameters listed below related to each application-functionality service.
Identify and describe infrastructure services
Infrastructure services including remote services may implement authentication, authorization, service registration and discovery, security monitoring, logging etc. Collect information on the parameters listed below related to each infrastructure service.
| Parameter name | Description |
|---|---|
| Service name (ID) | Unique service name or ID |
| Short description | Short description of functionality implemented by the service (e.g., authentication, authorization, service registration and discovery, logging, security monitoring, API gateway). |
| Link to source code repository | Specify a link to service source code repository (if applicable) |
| Link to the service documentation | Specify a link to the service documentation that includes service API definition, operational guidance/runbook, etc. |
Identify and describe data storages
Collect information on the parameters listed below related to each data storage.
| Parameter name | Description |
|---|---|
| Storage name (ID) | Unique storage name or ID |
| Software type | Specify software that implements the data storage (e.g., PostgreSQL, Redis, Apache Cassandra). |
Identify and describe message queues
Identify and describe data assets
Identify and describe data assets that processed by system microservices/services. It is advisable firstly to identify assets, which are valuable from a security perspective (e.g., “User information”, “Payment”). Collect information on the parameters listed below related to each asset.
| Parameter name | Description |
|---|---|
| Asset name (ID) | Unique asset name or ID |
| Protection level | Specify asset protection level (e.g., PII, confidential) |
| Additional info | Add clarifying information |
Collect information on the parameters listed below related to each “service-to-storage” relation.
| Parameter name | Description |
|---|---|
| Service name (ID) | Specify service name (ID) defined above |
| Storage name (ID) | Specify storage name (ID) defined above |
| Access type | Specify access type, e.g. “Read” or “Read/Write” |
Identify “service-to-service” synchronous communications
Collect information on the parameters listed below related to each “service-to-service” synchronous communication.
Identify “service-to-service” asynchronous communications
Collect information on the parameters listed below related to each “service-to-service” asynchronous communication.
| Parameter name | Description |
|---|---|
| Publisher service name (ID) | Specify publisher service name (ID) defined above |
| Subscriber service name (ID) | Specify subscriber service name (ID) defined above |
| Message queue (ID) | Specify message queue (ID) defined above |
| Short description | Shortly describe the purpose of communication (receiving of information or commands for a state-changing business function) and data passed between services (if possible, in therms of assets defined above) |
Identify “asset-to-storage” relations
Collect information on the parameters listed below related to each “asset-to-storage” relation.
| Parameter name | Description |
|---|---|
| Asset name (ID) | Asset name (ID) defined above |
| Storage name (ID) | Specify storage name (ID) defined above |
| Storage type | Specify storage type for the asset, e.g. “golden source” or “cache” |
It is advisable to create graphical presentation of application architecture (building blocks and relations defined above) in form of services call graph or data flow diagram. In order to do that one can use special software tools (e.g. Enterprise Architect) or . See example of using DOT language here.
Attack surface analysis
Implementation tips
To enumerate microservices endpoints that need to be tested during security testing and analyzed during threat modeling analyze data collected under the following sections:
- Identify and describe application-functionality services (parameter “API definition”)
- Identify and describe infrastructure services (parameter “Link to the service documentation”)
Mapping to OWASP projects
Implementation tips
To analyze possible data leakage analyze data collected under the following sections:
- Identify and describe data assets
- Identify “service-to-storage” relations
- Identify “service-to-service” asynchronous communications
- Identify “asset-to-storage” relations
Mapping to OWASP projects
Application’s trust boundaries, components, and significant data flows justification
Implementation tips
To verify documentation and justification of all the application’s trust boundaries, components, and significant data flows analyze data collected under the following sections:
- Identify and describe application-functionality services
- Identify and describe infrastructure services
- Identify and describe data storages
- Identify and describe message queues
- Identify “service-to-storage” relations
- Identify “service-to-service” synchronous communications
- Identify “service-to-service” asynchronous communications
Mapping to OWASP projects
Analysis of the application’s high-level architecture
Implementation tips
To verify definition and security analysis of the application’s high-level architecture and all connected remote services analyze data collected under the following sections:
- Identify and describe application-functionality services
- Identify and describe infrastructure services
- Identify and describe data storages
- Identify and describe message queues
Mapping to OWASP projects
Implementation of centralized security controls verification
Implementation tips
To verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls analyze data collected under the section “Identify and describe infrastructure services”.
Mapping to OWASP projects
Enforcement of the principle of least privilege
Implementation tips
To define minimally needed microservice permissions analyze data collected under the following sections:
- Identify and describe application-functionality services (parameter “API definition”)
- Identify “service-to-storage” relations
- Identify “service-to-service” synchronous communications
- Identify “service-to-service” asynchronous communications
Mapping to OWASP projects
Implementation tips
- Identify and describe data assets
- Identify “asset-to-storage” relations
Mapping to OWASP projects
Application components business/security functions verification
Implementation tips
To verify the definition and documentation of all application components in terms of the business or security functions they provide analyze data collected under the following sections (parameter “Short description”):
- Identify and describe application-functionality services
