Micro-Service architecture has no doubt proven to be the anti-dote the industry needs to deal with complexities of monolith applications that organizations have built and nurtured over the last couple of decades! Lot of organizations are at a point where monolith applications that are their bread and butter, now stifle innovation and are cost prohibitive to maintain!
So, what is the problem?
Monolith applications were in a way good for security, where you put all your eggs in one basket and watched it closely! Now with micro-service architecture, specifically in large organizations, security teams are being challenged to support variety of platforms, languages and frameworks that the Development teams want to use that is the best fit for the problem they are trying to solve. The Development teams say that as long as the contract for an API remains the same, how does it matter what tools/technologies are used under the covers to implement those APIs. Fair question, isn’t it?
In order for a security control to be effective, one needs to design, implement and be able to verify that the control is configured and is working properly within the context of the application. This new paradigm challenges the Security Teams as we need to understand how these platforms, languages and frameworks work, so that we can offer security best practices that the teams need to follow and the security anti-patterns that the teams need to avoid!
Let me offer you couple of examples to illustrate the challenges that the Security teams face in this new paradigm.
1. Let us say, you need to implement Authorizations in a Java based micro-services. There are many ways to solve this problem:
- Java provided JSR-250 authorization annotations
- Spring Security framework
- Apache Shiro
- Custom solution etc.
If you allow Developers to pick any of these authorization frameworks, how do you know if the frameworks are being used effectively? For e.g., Spring Security has so many nuances that we can not expect Development teams to understand the nuts and bolts of the framework to use it the right way. Just having an authorization annotation does not guarantee that the authorization is being enforced unless Spring Security is configured properly!
For e.g., the authorization checks at the URI level are based on the sequence of URIs specified in the Spring Security configuration where the first match wins. There are scenarios where if the sequence is incorrectly specified, authorization checks may not be triggered on a secure end-point even though authorization annotation exists at the method level. The Developers must have a robust suite of automated test cases to verify that Spring Security is configured correctly and authorizations are working as expected in their applications.
2. Input validations are another area of concern.
The crux of input validations is the regex that sits behind the input validator. In the absence of an enterprise wide input validation library, it is for each team to figure out the regex and it is not trivial to get the regex correct! The Developers either due to lack of expertise in creating regex or short of time, would come up with weak regex such as “.*” that allows any character and essentially the input validator does nothing to check if the application is consuming dangerous input from un-trusted control sphere.
I get the problem, but how do I solve this?
This is where the conundrum comes in: How do you allow Developers flexibility so that they can deliver business functionality faster with out compromising on security?
If you allow the Development teams flexibility to pick and choose any which way they want to solve the problem, this imposes burden on the security teams to understand the nuances of each framework, the best practices to follow and security anti-patterns to avoid.
There is no one size fit all, but, this is my proposition. Both sides have to give-in a bit and meet some where in the middle! Let me elaborate!
For a long time, Security teams have provided one set of enterprise controls for the Development teams to use and created policies enforcing that the Development teams use those controls. Instead of forcing everybody to use the same set of controls, security teams must look to support 3 to 5 (or some manageable set) platforms/languages/frameworks and allow flexibility so that Development teams do not feel constrained to use a Hammer where a Screw Driver would have been efficient! Security teams must strive to expand the tool box that is available for the Development teams and the correct size of the tool box is dependent upon your organization!
The answer lies in having the Security Teams and Development teams collaborate to mature re-usable security patterns, libraries, code snippets in the new platforms/languages/frameworks that Development Teams want to use. And for sure hold Development teams accountable for security vulnerabilities found in their applications. Remember, with great power comes great responsibility!