Tech Tapas Tuesday-"A little bit of tech": Principle of Least Privilege

What is the principle of least privilege? This is Tech Tapas Tuesday. Let's go. Application security is a critical aspect of all application design and architecture. Security best practices specify that nobody should be given universal access to any system or service. Instead, a given service system or person should be given only the access required to get their job done, and absolutely no more permission than that. To give someone more access than they absolutely need is to open up a potential security vulnerability. This security best practice practices known as the principle of least privilege. In service based applications, such as those built using service and microservice architectures, many components can become compromised. If even a single component is compromised, the entire application is at risk unless proper security procedures are already in force. Let's think about a simple example. Let's suppose we have an application and we are communicating between two services within the application by sending messages over a queue. AWS offers such a queue service known as SQS. Using SQS, you can assign permissions to insert entries into the queue or remove entries from the queue. In our example, let's assume that service A has to insert messages into the queue, and the messages are read off the queue by service B. So both service A and service B need access to this queue, but the two services need different permissions. Service A needs to insert messages into the queue, but it doesn't need to be able to read messages from the queue. Service B needs to read messages from the queue, but not insert them into the queue. A simplistic implementation of the security for this queue would be to grant full access to the queue to both service A and service B, and probably any other component within the application. After all, nobody but service A would ever attempt to write a message into the queue, so why restrict them from trying? And no other service, but service B would ever try to remove a message from the queue, so why prevent them from doing so? But what happens if another service, let's say service C, is deployed with a bug in it. As a result of the bug service C starts writing messages into the queue it ist supposed to be using? You now have a rogue service, service C, sending messages to service B. This will likely cause service B to malfunction. Now, let's assume the service C didn't simply have a bug, but let's assume it had malware in it. Service C could now maliciously attack service B by writing messages into the queue that could cause service B to malfunction. So either because of an accidental bug or because of some bad actor attack, service C is suddenly causing service B to fail simply because service C was allowed to write into a queue that had absolutely no business to write into. Using the principle of least privilege, you would not let this happen. You would not leave the queue open to any service in the application to access. Instead, you would put a more detailed security policy in place and make it so only service A could write messages into the queue and only service B could read messages from the queue. If this security policy was in place when service C went rogue, it could attempt to write bogus messages into the queue, but it would fail because it didn't have the right permissions. Service C would still be failing, but it would not also bring down B with it. The principle of least privilege is designed to help reduce their risk from this sort of problem, and reduce bad actor attack vector possibilities. The principle of least privilege would require setting specific itemized permissions for all services, resources, and systems, and disallow any non-needed actions from occurring. By locking down the queue, you remove a failure mode of the application and remove a potential bad actor attack vector at the same time. This is the value of the principle of least privilege. Thank you for listening to Tech Tapas Tuesday. Tech Tapas is short topic, mini episodes on a technology topic of interest. We release them occasionally on Tuesdays on the Modern Digital Business Podcast. To make sure you get every new episode when they become available, click subscribe into your favorite podcast player, or go to mdb.fm/listen or go to leeatchison.com. Thank you for listening and welcome to the modern world of the modern digital business.