Objective. The microservice architecture is being increasingly used for designing and implementing application systems in both cloud-based and on premise infrastructures. There are many security challenges need to be addressed in the application design and implementation phases. In order to address some security challenges it is necessity to collect security-specific information on application architecture. The goal of this article is to provide a concrete proposal of approach on how to collect microservice-based architecture information to securing application that can be applicable in immature processes and agile development. Method. In this paper, we conduct a systematic review of major electronic databases and libraries and analysis of several practical use cases related with security architecture reviews. Results and practical relevance. In this work based on research papers and several practical use cases analysis, we presented method for collecting architecture security-specific information for microservice-based applications and recommendations for applications security architect on how to use collected information to provide application verification against OWASP ASVS standard.
Imagine that you are an application security engineer that was recently hired by a small young
company or startup without any matured development processes. The application that company
developed is microservice-based application system and you are the only one person responsible for
application security. You probably use GOST R 56939, OWASP SAMM or other secure development
lifecycle framework [
The goal of this article is to offer some concrete proposal of approach on how to collect microservice-based architecture information and collected information to secure application. In summary, this paper makes the following contributions: • method for collecting architecture security-specific information for microservice-based applications (Section 2); • recommendations for applications security architect on how to use collected information to provide application verification against OWASP ASVS (Section 3).
Microservice architectures has emerged as a new architectural style allowing building application systems by composing lightweight services that perform very cohesive business functions [12]. Security threats and countermeasures for microservice-based system is a very important theme nowadays. Recent studies [13, 14] shows that that unauthorized access, sensitive data exposure and compromising individual microservices are the most treated and addressed threats by contemporary studies and auditing, enforcing access control, and prevention based solutions are the most proposed security mechanisms for microservice-based systems.
This chapter contains information about proposed method on how collect architecture securityspecific information for microservice based-system and prepare graphical representation of modeling application system. 2.1.
Step 1. First steps to identify and describe application-functionality services that are the services that implement business-related functions like storing customer details, storing and displaying product catalog. It is advisable to collect the following information related to each microservices: • unique service name or ID; • short (one or two sentences) description of business process or functionality implemented by the microservice; • link to source code repository; • development team which develops the microservice because it is usual to have several development teams are working on product; • API definition (e.g., OpenAPI specification) that describes interfaces exposed by microservice.
It is also advisable to collect some additional information like link to the microservice runbook or microservice internal architecture description, it is not necessary but it may help you. You should not collect too much information, e.g. information about 3rd-party components or libraries used in microservice can be extracted from source code repository via analyzing pom-files or similar artifacts. For application example provide on the Fig.1 during step 1 we capture information about following services: “User info”, “Booking”, “Frontend app” and “Admin”.
Step 2. Second step is to identify and describe infrastructure services. Infrastructure service is general-purpose service including remote services that does not implement any business-related functionality. Examples are: service registration and discovery, API gateway, security token service or OAuth authorization service or logging service. It is advisable to collect the following information related to each infrastructure service: • unique service name or ID; • 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; • link to the service documentation that includes service API definition, operational guidance/runbook, etc.
To collect this information you can investigate project repositories and collaborate with System architect/Development Lead. For application example provide on the Fig.1 during step 2 we capture information about following services: “Security Token Service”, “API Gateway” and “Service Registry”.
Step 3. The next step is to identify data storages. It could be database management systems or caches. You should collect a following information's related to each storage: • unique storage name or ID; • software that implements the data storage (e.g, “PostgreSQL”, “Redis”, “Apache Cassandra”).
For application example provide on the Fig.1 during step 3 we capture information about PostgreSQL database instance (“PG”).
Step 4: Identify and describe message queues
Because event-driven architecture is widely adopted pattern there should be messaging systems in application architecture like Apache Kafka or RabbitMQ. So, step number four is to identify those messaging systems and collect information on: • unique message queue name or ID; • software type, i.e. software that implements the message queue (e.g., RabbitMQ, Apache Kafka).
For application example provide on the Fig.1 during step 3 we capture information about “Apache Kafka” instance.
Step 5. And the final step dealing with collecting information on the building blocks is to identify data assets. That step is more intelligent that other because you cannot just inspect you repositories or execute a command to list data assets. To identify data assets you should actively collaborate with other member of you team like system analyst, product owner or business architect. Obviously, you could not identify all data assets at once – so 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 • • unique asset name or ID; asset protection level (eg, PII, confidential). 2.2.
Next steps after identification of application building blocks is to collect information on relations between those building blocks. The typical relation types are: • “service-to-storage” relations; • “service-to-service” synchronous communications; • “service-to-service” asynchronous communications; • asset-to-storage” relations.
Step 6. Identify “service-to-storage” relations. Collect information on the parameters listed below related to each “service-to-storage” relation: • service name (ID); • storage name (ID); • access type, i.e. specify access type, e.g. “Read” or “Read/Write”.
For application example provide on the Fig.1 during step 6 we may e.g., capture information about “User info” to “PG” relation.
Step 7. Identify “service-to-service” synchronous communications. Collect information on the parameters listed below related to each “service-to-service” synchronous communication: • caller service name (ID); • called service name (ID); • protocol/framework used, i.e. specify protocol/framework used for communication, e.g. HTTP (REST, SOAP), Apache Thrift, gRPC; • shortly describe the purpose of communication (requests for query of information or request/commands for a state-changing business function) and data passed between services (if possible, in terms of assets defined above).
For application example provide on the Fig.1 during step 7 we may capture information about “Admin” and “Security Token Service” synchronous communications.
Step 8. Identify “service-to-service” asynchronous communications. Collect information on the parameters listed below related to each “service-to-service” asynchronous communication. • publisher service name (ID); • subscriber service name (ID); • message queue (ID); • 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 terms of assets defined above).
For application example provide on the Fig.1 during step 3 we may capture information about “Booking” and “Admin” asynchronous communications.
Step 9. Identify “asset-to-storage” relations. Collect information on the parameters listed below related to each “asset-to-storage” relation: • Asset name (ID); • Storage name (ID); • Specify storage type for the asset, e.g. “golden source” or “cache”. 2.3.
It is advisable to follow “architecture-as-a code” [
front_end -> {API_GW} [label = "HTTPS"] } } subgraph api_gateways {
API_GW -> {AuthN, ms_1, ms_2, ms_3} [label = "HTTP"] } subgraph microservices { ms_1 -> {DB} [label="JDBC"] ms_2 -> {Queue} [label="gRPC"] ms_3 -> {Queue} [label="gRPC"] }
That code can be transformed to the following graphical presentation (Figure 2).
Collected information may be useful for doing application security practices, e.g. during defining security requirements, threat modeling or security testing [15]. This section contains examples of activities related to securing application architecture as well as its mapping to OWASP ASVS [16] requirements and tips for their implementation using information collected above. This implementation tips and recommendations were extracted and collected during multiple security architecture reviews.
Verify the use of threat modeling Collected information can be used for threat for every design change or sprint modeling purpose. Please see example listed after planning to identify threats, plan the tables. for countermeasures, facilitate appropriate risk responses, and guide security testing.
Verify documentation and To verify documentation and justification of all the justification of all the application's application's trust boundaries, components, and trust boundaries, components, significant data flows analyze data collected during and significant data flows. following steps: • Step 1 “Identify and describe application
functionality services”; • Step 2 “Identify and describe infrastructure
services”; • Step 3 “Identify and describe data
storages”; • Step 4 “Identify and describe message
queues”; • Step 6 “Identify “service-to-storage”
relations”; • Step 7 “Identify “service-to-service”
synchronous communications”; • Step 8 “Identify “service-to-service”
asynchronous communications”.
Verify definition and security To verify that analyze data on application analysis of the application's high- architecture collected during following steps: level architecture and all • Step 1 “Identify and describe applicationconnected remote services. functionality services”; • Step 2 “Identify and describe infrastructure
services”; • Step 7 “Identify “service-to-service”
synchronous communications”; • Step 8 “Identify “service-to-service”
asynchronous communications”.
Verify implementation of To verify that analyze data on application centralized, simple (economy of architecture collected during following step in design), vetted, secure, and order to derive what component provides reusable security controls to avoid authentication, authorization and logging: duplicate, missing, ineffective, or • Step 2 “Identify and describe infrastructure insecure controls services”. 1.1.4 1.1.5 1.1.6
Verify that communications between To enumerate microservices endpoints that application components, including need to be tested during security testing and APIs, middleware and data layers, are analyzed during threat modeling analyze data authenticated and use individual user collected under the following sections: accounts • Step 1 “Identify and describe application-functionality services” (parameter "API definition"); • Step 2 “Identify and describe infrastructure services” (parameter "Link to the service documentation") Verify that the application uses a single To verify that analyze data on application vetted authentication mechanism that architecture collected during following step in is known to be secure, can be extended order to derive what component provides to include strong authentication, and authentication: has sufficient logging and monitoring • Step 2 “Identify and describe to detect account abuse or breaches infrastructure services”.
Verify that all authentication pathways To verify that analyze data on application and identity management APIs architecture collected during following step in implement consistent authentication order to derive what component provides security control strength, such that authentication: there are no weaker alternatives per • Step 2 “Identify and describe the risk of the application infrastructure services”.
Verify that trusted enforcement points, such To verify that analyze data on as access control gateways, servers, and application architecture collected serverless functions, enforce access controls. during following step in order to derive Never enforce access controls on the client. what component provides authorization: • Step 1 “Identify and describe application-functionality services” • Step 2 “Identify and describe infrastructure services”.
Verify the application uses a single and well- To verify that analyze data on vetted access control mechanism for application architecture collected accessing protected data and resources. All during following step in order to derive requests must pass through this single what component provides mechanism to avoid copy and paste or authorization: insecure alternative paths • Step 2 “Identify and describe infrastructure services”. 1.2.3 1.2.4 1.4.4
Verify that logs are securely To verify that analyze data on application transmitted to a preferably architecture collected during following steps in order remote system for analysis, to understand how logging implemented: detection, alerting, and • Step 1 “Identify and describe applicationescalation functionality services”; • Step 2 “Identify and describe infrastructure
services”; • Step 7 “Identify “service-to-service”
synchronous communications”; • Step 8 “Identify “service-to-service” asynchronous communications”.
Here is an example on how to use collected information for threat modeling purpose. OWASP ASVS requires to use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing. During sprint planning an application security engineer can easily modify architecture diagram (see fig.3) or its part to reflect proposed architectural changes. Then, having updated diagram and description of services and data assets, you can make some threat modeling activities based on STRIDE methodology or similar, e.g.: • Does “Frontend App” really need connection to “Security Token Service”? If yes, what minimal privileges does that service need? • Does “Booking” service really need an access to “Admin” service? If yes, what minimal privileges does that service need?
Various techniques have been developed and applied to document microservice-based system architecture and use that information for security purposes but in most cases it can be applied in mature software development lifecycle processes and do not focus on application security aspects.
B. Mayer and R. Weinreich [17] presented an approach to extract and analyze the architecture of a microservice-based software system based on a combination of static service information with infrastructure-related and aggregated runtime (logged outgoing and incoming requests) information.
G. Granchelli et al. [18, 19] presented an approach for semi-automatically recovering design of microservice-based systems. Their approach is based on model driven engineering techniques usage and domain-specific language for representing the key aspects of the architecture of a microservicebased system.
S. Ma et al. [20, 21, 22] proposed an approach to the development of microservice-based systems that enables the automatic generation of a service dependency graph by which to visualize and analyze dependency relationships between microservices as well as between services and scenarios. It also enables the automatic retrieval of test cases required for system changes to reduce the time and costs associated with regression testing.
N. Riopelle et al. [23] proposed the use of dependency graph based modeling to streamline the failure analysis process for private cloud and microservice-based applications.
Y. Lan et al. [24] proposed and designed a dependency model of microservices and dependency mining method based on call chain logs to extract local dependencies and the discontinuous dependency relationship.
N. Chondamrongkul et al. [25] presented an automated security analysis approach for microservice architecture that can automatically identify security threats according to a collection of formally defined security characteristics and provide a result that demonstrates how the attack scenarios may happen.
Compared with the related works our study is more narrow and concentrated on security of microservice-based system, whereas most of the above-mentioned work considers some quality characteristics. In contrast with above-mentioned works we are not only take into account microserviceto-microservice dependency but also dependencies on general purpose services (like API Gateway and service Discovery), data storages and messages queues. Moreover, to design our graph we use object called “asset” (in contrast with [25]) that allows us to cover more security checks from OWASP ASVS.
In this paper, we presented a method for collecting architecture security-specific information for microservice-based systems that can be used even in immature software development processes to secure application. Collected information may be useful for doing application security practices during defining security architecture: attack surface analysis, data leakage analysis, analysis of the application's high-level architecture, enforcement of the principle of least privilege and sensitive data identification and classification in secure software development lifecycle. We tested our approach during development of microservice-based system in Oil & Gas automation and received a positive feedback. We also contributed that approach to OWASP Community in Cheat sheet series. Practical usage of proposed light-weight method for collecting security-specific architectural information for microservice-based systems allowed to decrease the time for collecting application design information and to focus more on practical security aspects (like threat modeling) during sprint planning.
Further research is intended for combining graph algorithms with proposed approach in order to automate steps needed to design microservice application design and make threat modeling for largescale distributed microservice-based applications.
[11] E. Yuan, "Architecture Interoperability and Repeatability with Microservices: An Industry Perspective," 2019 IEEE/ACM 2nd International Workshop on Establishing the Community-Wide Infrastructure for Architecture-Based Software Engineering (ECASE), Montreal, QC, Canada, 2019, pp. 26-33, doi: 10.1109/ECASE.2019.00013. [12] T. Yarygina and A. H. Bagge, "Overcoming Security Challenges in Microservice Architectures," 2018 IEEE Symposium on Service-Oriented System Engineering (SOSE), 2018, pp. 11-20, doi: 10.1109/SOSE.2018.00011. [13] Abdelhakim Hannousse, Salima Yahiouche. Securing microservices and microservice architectures: A systematic mapping study, Computer Science Review, Volume 41, 2021, 100415, ISSN 1574-0137, https://doi.org/10.1016/j.cosrev.2021.100415. [14] Nuno Mateus-Coelho, Manuela Cruz-Cunha, Luis Gonzaga Ferreira. Security in Microservices Architectures, Procedia Computer Science, Volume 181, 2021, Pages 1225-1236, ISSN 18770509, https://doi.org/10.1016/j.procs.2021.01.320. [15] Varenitca V. V., Markov A. S., Savchenko V. V. Recommended Practices for the Analysis of Web Application Vulnerabilities. 10th Anniversary International Scientific and Technical Conference on Secure Information Technologies, BIT 2019 CEUR Workshop Proceedings. Volume 2603.
Moscow, 2019, pp. 75-78. [16] S. Elder, N. Zahan, V. Kozarev, R. Shu, T. Menzies and L. Williams, "Structuring a Comprehensive Software Security Course Around the OWASP Application Security Verification Standard," 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering Education and Training (ICSE-SEET), 2021, pp. 95-104, doi: 10.1109/ICSESEET52601.2021.00019. [17] B. Mayer and R. Weinreich, "An Approach to Extract the Architecture of Microservice-Based Software Systems," 2018 IEEE Symposium on Service-Oriented System Engineering (SOSE), Bamberg, 2018, pp. 21-30, doi: 10.1109/SOSE.2018.00012. [18] G. Granchelli, M. Cardarelli, P. D. Francesco, I. Malavolta, L. Iovino and A. D. Salle, “Towards Recovering the Software Architecture of Microservice-Based Systems,” in IEEE International Conference on Software Architecture Workshops. IEEE, Apr. 2017, pp. 46–53. [19] G. Granchelli, M. Cardarelli, P. D. Francesco, I. Malavolta, L. Iovino, and A. D. Salle, “MicroART: A Software Architecture Recovery Tool for Maintaining Microservice-Based Systems,” in IEEE International Conference on Software Architecture Workshops. IEEE, Apr. 2017, pp. 298–302. [20] S. Ma, C. Fan, Y. Chuang, W. Lee, S. Lee and N. Hsueh, "Using Service Dependency Graph to Analyze and Test Microservices," 2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC), 2018, pp. 81-86, doi: 10.1109/COMPSAC.2018.10207. [21] Shang-Pin Ma, Chen-Yuan Fan, Yen Chuang, I-Hsiu Liu, Ci-Wei Lan. Graph-based and scenariodriven microservice analysis, retrieval, and testing. Future Generation Computer Systems, Volume 100, 2019, Pages 724-735, ISSN 0167-739X, https://doi.org/10.1016/j.future.2019.05.048. [22] S. Ma, I. Liu, C. Chen, J. Lin and N. Hsueh, "Version-Based Microservice Analysis, Monitoring, and Visualization," 2019 26th Asia-Pacific Software Engineering Conference (APSEC), 2019, pp. 165-172, doi: 10.1109/APSEC48747.2019.00031. [23] N. Riopelle, A. Malatpure, S. Ashtekar and V. Raman, "Dependency Graph Based Failure Analysis for Private Clouds," 2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW), 2019, pp. 25-29, doi: 10.1109/ISSREW.2019.00037. [24] Y. Lan, L. Fang, M. Zhang, J. Su, Z. Yang and H. Li, "Service dependency mining method based on service call chain analysis," 2021 International Conference on Service Science (ICSS), 2021, pp. 84-89, doi: 10.1109/ICSS53362.2021.00021. [25] N. Chondamrongkul, J. Sun and I. Warren, "Automated Security Analysis for Microservice Architecture," 2020 IEEE International Conference on Software Architecture Companion (ICSAC), 2020, pp. 79-82, doi: 10.1109/ICSA-C50368.2020.00024.