We can identify several risk factors but thankfully, we can also refer back to some design patterns. Let’s explore a few of them.
In some modern applications, the whole application is seen as having certain privileges such as an application that is allowed to view documents on a drive. This is not a great way of thinking because it means that once our code is eventually hacked, the attacker has a much bigger attack surface.
It’s much better to divide our applications into processes that allow us to grant certain privileges to the required processes. If our application gets a hacker, this would mean an attacker would have a much smaller attack surface.
When creating applications, the need might arise to separate users by a need-to-know or a privilege level category when it comes to information and processes. To facilitate this, we need a system and it’s usually called Multi-level security. This is also known as authorization.
We need to create a system that allows us to separate users into different categories. Based on that category they might need access to a process or to a domain of information. We need to be able to either allow or deny access to certain parts of our application. To facilitate this we have to start from the design of the application and take security consideration into account from day 1. Retroactively adding a multi-level security system can prove difficult with missing documentation and might even lead to accidental skipping of information, allowing users access to much more information than they should have.