Skip to content

An incomplete list of practices to improve security of your (micro)services

Published: at 07:45 PM

Software security is hard and complex. Many people think about it as something aside from the typical development process. It’s usually seen as a responsibility of some security people that only care about security and don't understand that we need to deliver business value fast in an already complicated microservices-event-driven-api-frist-ha-cloud ecosystem. I could add a lot more dashes to microservices-event-driven-api-frist-ha-cloud. And I think this is the main reason it might seem overwhelming to think early about security and all the possible cases something or someone can break your system. It’s yet another complex thing in an already complex environment. It’s not just all the technical complexities of modern architectures, it’s also all the additional stuff: need to go to market fast, hard deadlines, team chemistry issues, underperformers, too many processes, meetings, etc. And it’s a complex thing that will not break your system in day 1. It might take months/years until someone will find a vulnerability. Why focus on this from day 1? Well, you might be right. The chances of something happening from day 1 are low. And it’s very tempting to focus on something with immediate value (actual functional features), rather than mitigating some future possibilities. The thing is, when a security issue happens, it can bring your entire system down. And this will be very bad for you and your users.

I see it similar to airport security. We do all these checks, we scan people, we forbid them to take things onboard and so on, although 99.99..9% of people don’t plan to hijack the plane. It’s for the 0.00..1% of the cases that we have all these measures in place. Because the consequences are big.

So how do you balance between not over-engineering security and be paranoiac about everything while still focusing on the business value? You make it a mindset, rather than a separate concern. I’m not saying that everyone needs to become a security expert and know everything. I’m saying that people should develop secure software just like they develop software. They do it in a way that will minimize the probability of introducing vulnerabilities.

The best way to instill this mindset is through a set of standards and practices that will create habits. Going back to airport security, you don’t let all the decisions on each individual security person. “This person looks nice. Let them have the scissors, and a knife in their hand luggage”. “You sir look very dehydrated, you can take your big bottle of liquid with you in the plane!” You create a set of rules, procedures (i.e., standards) that will apply equally to everyone. And you also create a set of guidelines (i.e., practices) on how to handle specific situations: if you see something suspicious in a hand luggage, you inspect it separately.

In the next sections I’ll detail standards and practices that cover the entire SDLC. They are not meant to be self-sufficient for all sections (i.e., you might add a lot more to cover that section from a general good practices perspective). But they will make you questioning things and think about cases that are not maybe that obvious.

Where is Security focused

I’ll do a simple split of Security concerns into two main areas:

There are plenty of resources on how to tackle both:

They are lengthy, comprehensive and include a lot of details and practices on how to tackle security in SDLC. It will be great if every developer will go through all these periodically in order to keep their information fresh. But in practice, this doesn’t happen quite often. I’ll try to summarize below which are the most important things to consider, agnostic of the business domain. It’s not a full list, nor a silver bullet. But it will establish a solid foundation which will minimize the possibility for security issues to happen.

Tackling Security

Infrastructure Security it’s more predictable to address, mainly due to the use of products or cloud services. They already have the security features build-it and implemented well i.e., if you use a Web Application Firewall, you trust the product to do its job, you won’t actually implement its logic. I’m not saying it’s easier, but you have more control.

Application Security it’s less predictable. You mainly rely on people skills to implement stuff securely. You need to make sure they don’t do stupid things like storing clear text passwords in source files.

Below is a list of the most important practices which I think will help you build a security mindset. It’s intended for the regular developer. When I say regular, I just mean people actually implementing, rather than all the others focused on designing, planning or managing. They are all focused on Application Security for building (REST) APIs. At a first glance they might not seem all directly related to security. But in the end, they will minimize the probability to introduce security issues.

Majority of examples will use Java.

Standards

As mentioned above, the usage of standards is the main mechanism to build a mindset. All projects should have a set fo standards. Not everyone is a fan of standards and feel they limit people’s choices and creativity. But I think it’s an easy way to get consistency, especially when having many teams working on the same platform. It allows both easier onboarding for new joiners and limit the possibility of introducing bugs or inconsistencies or argue for stupid things (spaces vs tabs ;)). It gives you more time for meaningful discussions and debates. Standards do not have to be very detailed, at least not in all areas. The majority of the standards should state principles and choices you’ve made based on existing sets of good practices.

Documentation

Key things to consider:

General (micro)services design guidelines

Key things to consider:

Code formatting/styling

Just choose one and apply it consistently. Auto-format before commit if possible.

Naming conventions

Just choose one and apply it consistently.

API standards

Key things to consider:

Logging standards

Key things to consider:

Data standards

Key things to consider:

Processing Data

Key things toc consider:

Logging Data

Key things to consider:

Storing Data

Key things to consider:

Events/messaging standards

Key things to consider:

Configuration handling

Key things to consider:

Error handling

Key things to consider:

Branching strategy and commits

Key things to consider:

Code review

Key things to consider:

Tooling and 3rd party libraries

Key things to consider:

Code Analysis

Key things to consider:

Testing

Key things to consider:

CI/CD

Key things to consider:

Authentication and Authorisation

Key things to consider:

General Security Practices

Key things to consider:

Quality attributes

As we’ve seen above, SDLC standards and practices are not always directly related to security. Same applies for quality attributes. Shortcomings in current design and approach can cause your application to go down, even if it is not caused by a true security problem.

Key things to consider for Performance:

Key things to consider for Resilience:

Key things to consider for Availability and Scalability:

Key things to consider for Observability and Monitoring:

Automate

Automate everything. Automation makes it predictable and consistent. The CI/CD pipeline should be the place where you automate all checks that will assess your (micro)service from a quality perspective. Tools like Semgrep can bring automation with less effort for standards not obviously suited for automation.

Conclusion

This isn’t a final list, it’s more like a brain dump. It’s a starting point for building a security mindset. Once you apply all these, you are ready to deep dive. Applying all these practices won’t give you only security benefits, but also more structure and alignment. This is particularly important in systems developing too fast, either brand new or legacy. You don’t need to go with all these from day 1, it might seem overwhelming especially if you are not used to following common standards and think it will limit your options. But maybe you can try it for a while and see what happens!