Monday, November 27, 2017

Security Boundaries

Knowing the security boundaries of our applications help building safer code. Read to understand.

In order to properly implement secure applications, developers should understand the concept of security boundaries (or trust boundaries) in the context of software development/architecture.

So let's start with a solid definition. According to IEEE, security boundaries are:
defined by a set of systems that are under a single administrative control. These boundaries occur at various levels, and vulnerabilities can become apparent as data “crosses” each one.
A good guideline to understand what the security boundaries of your app are is by:
  • examining their applications from both functional and technical perspectives;
  • understanding and evaluating the boundaries in and between their applications;
  • taking into account all the interfaces and integrations to/from their systems;
  • knowing that vulnerabilities can be propagated from one boundary to the other, possibly affecting not only your application but also leaking to your users;

Trust Model

how an organization determines who to trust with its assets or pieces of its assets.
As developers, we could use the same paradigm by considering:
  • who should have access to my system;
  • what can they access;
  • which internal components in my application I trust, which I don't;
  • which external components in my application I trust, which I don't;
With all that information you should be able to draw lines (security boundaries) around your architecture, helping you identify what are the trust levels between those boundaries.

Performing security verification

Once we know which are the boundaries of our apps, we could reduce the development effort to check security only in the application boundaries. For example: if my web app talks exclusively (is coupled) to my backend and vice versa, it's fair to say that I only need to validate my data once.
But don't treat that as a general rule. Actually, I would treat that as an exception as applications today are getting more and more complex.

Security checks in the cloud

What if my web app talks exclusively to my backend via a message queue or a storage account in the cloud? Is it safe to say that I should trust everything that reaches the backend? Of course not. After all, being the transport layer publicly available, it could be compromised. Being compromised, messages reaching the backend might also be compromised, resulting in breaches in my system. I should validate them whenever possible.

Every new element we add to our architecture is another element in the security boundary equation: should I trust everything that comes from it or not?

Security checks with Different Networks

Same for applications in different networks. Just by adding a public network between them, means that the information we're getting (if not encrypted) might have been tempered with. Should we trust it? The answer to that is related to how trustable our network is. Being a private vnet in the cloud, I would be ok. Public, not so much.

Local Security checks

In the same process

For two assembly in the same process for example, I don't think no security checks needs to be done. However, if two applications share the same process and a component in one calls a component in the other, a security check should be done because we crossed an application boundary.

In with different Processes

Likewise, if two applications reside in different server processes and a component in the first application calls a component in the second application, a security check is done.

Final Thoughts

I briefly introduced the concept of security (or trust) boundaries in this post. I hope you use that information to, in the future, evaluate how your company is treating the data you are injecting from your users and 3rd-party APIs.

See Also

About the Author

Bruno Hildenbrand      
Principal Architect, HildenCo Solutions.