In the past, building an application meant just that: a single, monolithic application built by a single team. When the application was updated, any change required a full code update, rebuild, and redeployment. Teams needed to retest and redeploy the entire application. That meant software engineers spent a lot of time making sure the application continued to operate instead of focusing on added value. 

The need for more agility – faster time to market, better developer productivity, and integration with operations – drove teams to look for a different approach that broke a monolithic application into discrete components. In this blog, we will forego the history of component development with 3-tier and n-tier applications.  Rather, we will fast forward to current software development practices with microservices.

Microservices 

A microservices architecture focuses on building small, well-defined, and targeted services that can be reused across multiple applications. Each microservice has a well-defined interface (API) and limited scope. This allows them to be built, deployed, and maintained independently of other services or software features. Microservices can be written in different programming languages and use different data stores, making rapid updates and deployment easier.

An application built using this architecture can include multiple services (sometimes hundreds) of services, each with multiple instances. To deal with the complexity of service-to-service communication, applications often use a service mesh. A service mesh is a dedicated infrastructure layer in the application. It operates as a proxy for each microservice and abstracts the logic governing service-to-service communication from individual service layers. A service mesh can also provide authentication, authorization, and secure communication services between each microservice.

The benefits of microservices

• Scalability – Microservices are independently deployable services that communicate with each other. As parts of an application experience high demand, individual components can be scaled separately rather than scaling the entire application. 

• Maps to DevOps software development practices –  Microservice delivers a single complete software capability. This means each microservice can be developed without dependencies on other teams, leading to more rapid release cycles.

• Independence in technology – Since each microservice is separate, development teams are free to choose the best technology stack for the service being constructed. 

• Loose coupling – There are limited dependencies between any two microservices. Instead, each microservice contains all the logic required for the purpose of the microservice and all interactions with others are solely through well-defined APIs.

• Reusability – Because microservice are self-contained they can be used across multiple applications and  business processes

• Fault tolerance – A single service breakdown does not cripple the entire system.

Security challenges when threat modeling microservices

While adopting a microservices architecture can accelerate development and simplify maintenance and deployment, each microservice can present new security concerns. 

Heterogenous technical stack – An application using a microservices architecture may consist of hundreds of individual microservices written in several languages. Each programming language and framework presents different inherent weaknesses and risks. The resulting complexity can make it difficult to ensure that threat modeling teams conduct a thorough exercise. 

Increased attack surface – A monolithic application often has few entry points. In a microservices architecture, each microservice and API represents a new attack surface. As the number of services increases, so does the application’s attack surface.

Managing microservice credentials – With hundreds of individual microservices, ensuring proper authentication and authorization between them can be difficult. 

Residual risk – Vulnerabilities may still exist after threat modeling is performed. For example, development teams may borrow insecure code from sources like Stack Overflow which may not be caught by threat modeling. In line with defense-in-depth principles, developers must remain diligent to create secure code.

Security expertise – When there is pressure to release rapidly, developers may feel additional pressure to make security decisions for which they are not qualified. 

Best practices

• Defense in depth – Since each service has its own API and attack surface, security controls must be considered for each. 
• Adopt a security culture – Each microservice team must take responsibility for the security of its software. Making security champions part of each team can help extend scarce security resources.
• Use dependency tracking – Open source components make up a majority of the average application. Thousands of new vulnerabilities are disclosed in these components each year. Keep track of the dependencies and map them to reliable vulnerability sources.
• Default to encryption – Encrypting data at rest is obvious. Teams should also encrypt data in transit between users and systems to prevent attackers from intercepting or monitoring plaintext data transmissions.
• Issue and expire credentials quickly – Avoid long-running trusted connections and apply it to every interaction with a system.
• Abstract away complexity – Breaking the function of each service as small as possible and communicating through APIs make the task of each development team simpler.
• Service independence – A microservices architecture is designed for independence. Allow each team to update their service independently of other teams.
• Decouple security policies – Decouple code from security policies by placing security policies at the front-end service proxy.

Making microservices threat modeling scale

Traditional threat modeling is a manual process. Senior security, development, and compliance resources map out the application and threats over the course of days, then decide what mitigation controls are needed in the design and execution of the application. The time and expense of traditional threat modeling limits its use to an organization’s most critical applications. Updating a threat model in a rapidly changing DevSecOps environment is impractical. 

Automated threat modeling is a scalable, consistent, and auditable alternative. This starts by generating a list of threats based on the technical stack of each microservice, including its programming language, frameworks, and compliance requirements. Once the threats are identified they are translated into consistent, company-approved mitigation controls, including code samples and test plans, then assigned directly to development, security, and operations personnel through their existing tools (e.g., Jira, Archer).

Validation of all controls is automated through integrations with Automated Security Testing tools, including static analysis, dynamic analysis, and source composition analysis. This allows teams to have near real-time traceability of which have been implemented and which remain open.

All information on threats, risks, weaknesses, and controls is maintained in an updatable knowledge base. As regulatory standards, security policies, and mitigation strategies evolve, updates can be made once and propagated to each project.

Final thoughts

Microservices provide much-needed agility to support a business’ goal, allowing improved agility, faster time to market, and a truly distributed development environment. To be successful, security must be part of every project from the beginning. 

A threat modeling platform that integrates with development, security, and operations eases the security burden on those teams. Instead of depending on the skills, opinions, and experience of individual threat modeling teams, automated threat modeling provides a centralized, consistent, scalable, and auditable method to identify and mitigate risk. This requires a knowledge base that covers multiple languages, deployment environments, best practices, and regulatory standards.

You do not need a dedicated security team to start a threat modeling program. SD Elements identifies threats in software based on a short survey describing the application’s technical stack and deployment environment. It translates these into actionable controls, complete with sample code and test plans, and assigns them to development, security, and operations personnel through the tools they already use. SD Elements integrates with application security testing tools to provide near real-time reporting on the application’s security profile.

Want to learn more? You can book a demo with our team here.