The Ecosystem of Breaches -- Services

As we continue our tour of the ecosystem of breaches we get to services. Services are an interesting concept because we know that services are actually many different things.

In a pristine world of modern architecture, we have isolated microservices that can come online and go away as needed and have their own wrappers for security but we know that we're still dealing with mixtures of architecture with a mix of some microservices some full stack architecture and we may even have legacy systems that we're talking to.

These systems, be they the legacy systems or the full stack or whatever we create, seem to develop odd little back doors over time. Once someone finds these back doors and get in, they have a lot more access than just that one service. This is because most of these services, especially in a mixed architecture, have some sort of homegrown security that's going to be different on each type of service (microservice, full stack, legacy with a wrapper, etc.).

This often means you have vulnerabilities that you're not considering, and those vulnerabilities are particularly problematic in the legacy world of the data center where we feel that anything in that data center can be trusted.

Because we can't trust other services, we need to think of our data center as a zero-trust environment. There should be no anonymous access -- that is to say that just because Service A and Service B are sitting in the same network, they shouldn't be able to talk to each other willy-nilly.

Services should have identity so Service A should have not only a pair of keys so we know that Service A called to Service B but it should have a set of permissions that are specific to that service -- better yet, those credentials should be specific to the call that it's doing in that context, adding the upstream user's details including risk factor.

And then, if Service A asks service B to call out to Service Q, we should have some sort of logging that shows that Service B didn't just make this request independently. It should be recording the fact that Service A requested from something from Service B which cascaded to another request.

So, to sum up:

• Even new environments have a mix of tech that create security holes
• Services should have Identity
• That Identity should be contextual
• Everything should be logged
• Those logs should show tracing for cascading requests