Source – techtarget.com
Akshay Aggarwal: From going from a … monolithic design paradigm to a more distributed microservices design paradigm, the transition that we are seeing is driven by business efficiencies, economies of scale, as well as trying to make things simpler by reusing functionality across different applications. What that does to security is it simplifies certain aspects, but it makes other aspectsextremely challenging.
In the monolith world, we understood the software development process well and were able to introduce adequate controls in it over a period of time. But in the microservices world, because of the distributed nature, a few fundamental things have changed.
Can you talk about some of those changes?
Aggarwal: First, application endpoints have just proliferated, so you need to secure each of those independently. And there are two other aspects that are very interesting from the monolith world to the microservices world. One is the question of identity. In the monolith world, it’s easier to manage identity and access controls. You could trust information that was going through, or a token could persist and that made it simpler for some of the functionality. In the microservices world, it’s very, very difficult to understand and establish identity. We actually see many, many firms doing this wrong.
And the second big thing that’s changed from the monolith to the microservices world has been just the speed of deployment and rolling out functionality. You’re building smaller microservices; therefore, people are responsible for … a smaller portion of functionality. We’re seeing rapid churns and deployments of new code, and that is upending the traditional approach to security for a lot of firms.
What are the major areas where organizations are making mistakes implementing security in microservices?
Aggarwal: The microservices world has made things very complex for security individuals in organizations. But it’s also made it very difficult for QA testing and DevOps [teams] because it has taken some of the complexity and pushed it down to a DevOps space that didn’t exist before. So to me, when people talked about security from an API or a microservices perspective, very often, what they’re focusing on is the security of the container or the configuration management tool. So the guys are talking about something about Chef’s container configuration management tool or Tenable’s patch management tool for those containers as well.
All of that is great. But what they’re not focusing on is the fact that the way the software is being developed itself is completely different. So, let me give you a few examples of how software development and QA processes haven’t caught up to deal with the microservices world. If you have two individual components that exist, do they share the same namespace? And if they share different namespaces, do the involved identities still have common authentication credentials? That would be essentially like using the same password on two completely separate, unrelated websites.
And the second thing: If you’re deploying software on a weekly basis, how are you going back and verifying that your security tests are still accurate and your security posture hasn’t changed? Clearly, there is a significant need for automation of security testing for microservices and the API world, and that’s not happening. So, if you summarize this in basically one line, what I say is that the secure development lifecycle itself needs to evolve to engage with the microservices architecture, which it has not. Therefore, we see practices that are not optimal in the security of microservices.
Why do organizations lack the needed tooling and automation? Is it a budget issue, a lack of needed skills or something else?
Aggarwal: Certainly, it includes budgetary considerations, so they don’t want to spend the money. Second is that I don’t think CSOs or CIOs currently understand or appreciate the nature of how security has changed. That’s specifically because microservices security can be broken down into multiple tiers. So, one tier could be configuration management, another can be infrastructure security and a third tier could be runtime security. And a fourth, but very important, portion of microservices security is security testing during development — DevOps-focused security testing. That’s where you would get the maximum bang for buck, but there aren’t elegant solutions out there currently to do that. There is a growing awareness, but the awareness isn’t at the level at which it justifies spending.
On the flip side of this problem, we clearly know that there aren’t enough testers out there in the world that will be able to [keep up] with the speed of deployment and test APIs and microservices to a level that is satisfactory with the risk.
Do you think the lack of testers is a core issue as far as organizations not being able to secure things as well as they should?
Aggarwal: Oh, absolutely. Security skill sets in the QA and testing spaces are very limited from a human perspective. We just don’t have enough capable, qualified security QA testers available, period. So, they can’t scale; they’re not going to be able to meet the demands of the industry. From our perspective, we see that a very highly skilled security tester can perhaps test, in a very liberal perspective, a few hundred to up to a 1,000 test cases in a week. Automation can essentially do that in under an hour in some aspects. So, while I don’t think that [automation] displaces the need for security testing from testers, what it does need to do is be supplanted with automated testing.
I’ll give you a very specific observation. We work with some really large technology companies. Very often, they’re dedicating the vast amount of that security testing manpower to around 10% to 15% of that portfolio. The rest of the 85% of that portfolio of applications and software is essentially going untested in many scenarios. A large part of that is because they just cannot find enough qualified people to do that, and it’s very expensive to do that with people.
