Source – techtarget.com
In this Q&A, Daniel Bryant, CTO at SpectoLabs and an independent technical consultant, talks about some of the challenges that come up when addressing microservices security and some of the tools and techniques you can use.
Compared to more traditional architectures, what new challenges have microservices introduced in terms of security?
Daniel Bryant: In the traditional approach, you had one thing. So, if it was compromised, you’re in trouble. It’s like putting all your eggs in one basket kind of thing. The flip side of that is, when you break things up, suddenly, you’ve got to secure many more things. The attack surface gets much bigger. No longer are you doing things like hardening the edges, and then you won’t look behind it.
The biggest challenge now is that every developer has to be that much more conscious of security. There’s a lot more things, there’s a lot more attack surface and there’s a lot more communication going between all those things that is exposed.
What kind of tooling and techniques are important for microservices security?
Bryant: There are things like web application firewalls, [which are] very popular. A lot of companies I’ve worked with use things like F5, and they’re actually F5 firewalls. Increasingly, we’re seeing more software firewalls, even with Amazon.
That’s clearly prevention, but you also need to think about detection. So, basic stuff: logging low bands in traffic, logging the web traffic, logging SSH [Secure Socket Shell] access. [In] any public-facing web server, if you look through the logs, people are constantly probing the edges. [So,] you want to see [if it’s] only from this IP address or only from this country … you want to be doing sort of some kind of like continual analysis of where stuff is coming from.
[Also,] what attacks are there? What vectors are they trying to probe? If you’re not patching your systems, they may sort of get lucky one day. So, you definitely need detection and need to make sure everything’s patched up. [People will say:] ‘Yeah, we spend all this money on networks and on compute.’ That’s all great stuff, but don’t forget about the application. If the application has a massive vulnerability, all that other stuff is for nothing. It only takes one point of entry for someone to get in and start doing damage.
I definitely think things like threat modeling [are also] super useful. Understand how threats work, what threats there are and model how they might attack your system. And often, I find, a side effect of modeling things properly opens up my eyes to different ways things happen. So, if you start doing attack vectors, you suddenly think, ‘Well, I’m really hardening this thing in the application,’ where you realize there’s a massive flaw in your email system or something.
[And] OWASP [Open Web Application Security Project], they’re an awesome organization. They have a bunch of language sort of diagnostic tools for scanning for critical vulnerabilities in dependencies. So, if I’m using Java or Maven, I can put it in my Maven Palm. If I’m using Ruby, I can put it in my gems.
What’s the question everyone should be asking when it comes to microservices security?
Bryant: How can I contribute? Ask your team, ask your management, your leaders: What can I do? What’s my job in relation to our security? Should I be following certain standards? Should I be double-checking my work? These kind of things [are] the most critical.
I really think microservices security isn’t massively different to traditional security. As developers, we’re taking on more and more … I’ve got to be an operations person as well as the developer. You know, front end, back end, all these things. If you’re not careful, you become like sort of a mile wide and an inch deep.
But at the same time, if you as a developer are really well-educated across the stack but don’t know too much about security, it’s very easy to leave massive holes. If you leave some massive security holes, that’s potentially very bad. So, developing awareness, modeling, documenting, sharing, coming to conferences, chatting with people, learning as much as you can … those are all important.
What do you find that experts are still scratching their heads about when it comes to microservices security … the one thing that people still can’t really seem to get right?
Bryant: It’s not tacked [specifically] to microservices; it’s more of a case of as the world is getting more and more connected. There are things like bitcoin [that are] more and more attractive for attackers to attack now.
I think, as an industry, we’re not as responsible as we should be. So, it’s more of a case it’s just the human factor again. Are we paying enough attention to it as developers or as architects? Are we doing things like defense in depth? Are we doing things like auditing and logging and then looking back on those things? There’s some basic stuff like terms of coding which, we again, we don’t do.
When it comes to security, what was better in a traditional architecture like service oriented architecture (SOA) versus a distributed microservices architecture?
Bryant: Not much has changed in the principle point of view. The only thing I would say [is that], with SOA, we had a lot more governance. SOA was driven by the vendors’ law … [they] were saying, ‘You must use my ESB [enterprise service bus] or my [particular] technology.” There were a lot of disadvantages to that, but one of the advantages was that someone owned it. So, you have this ESB, this thing [managing] all the connections within your services [and it’s] their ass on the line basically. So, they really invested in policy and governance and all these kind of things. And if something went wrong, you knew who to call.
Whereas, these days, we go towards more lightweight technologies, but you have to take more responsibility as a developer and as an architect. The governance and policy and stuff, as bad as it sometimes was, there was an upside to it. It’s even the same with politics: the more control you have, the obviously less freedom you have, but it’s a balance that’s somewhere in there.
How can DevOps teams best work with security teams to ensure services are secured?
Bryant: The whole DevOps philosophy is about joining everyone together. So, a lot of consultancies I worked on we really try and bring in infosec [information security] — in a classic organization, they’re often called infosec. Bring them into the project early, because they’re generally good people, but they’re not consulted until things are going live. So, you have to get them involved earlier. Their knowledge is super valuable, so getting them involved earlier is great.