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 the job done, and absolutely no more permissions than that. To give someone more access than they absolutely need is to open a potential security vulnerability.

This security best practice is known as the Principle of Least Privilege.

This is Tech Tapas Tuesday, on Modern Digital Business.

{{useful-links-research-links}}

{{about-lee}}

{{architecting-for-scale-ad}}

{{signup-dont-miss-out}}

Transcript
Lee:

What is the principle of least privilege?

Lee:

This is Tech Tapas Tuesday.

Lee:

Let's go.

Lee:

Application security is a critical aspect of all application

Lee:

design and architecture.

Lee:

Security best practices specify that nobody should be given universal

Lee:

access to any system or service.

Lee:

Instead, a given service system or person should be given only the access

Lee:

required to get their job done, and absolutely no more permission than that.

Lee:

To give someone more access than they absolutely need is to open up

Lee:

a potential security vulnerability.

Lee:

This security best practice practices known as the principle of least privilege.

Lee:

In service based applications, such as those built using service and

Lee:

microservice architectures, many components can become compromised.

Lee:

If even a single component is compromised, the entire application

Lee:

is at risk unless proper security procedures are already in force.

Lee:

Let's think about a simple example.

Lee:

Let's suppose we have an application and we are communicating between

Lee:

two services within the application by sending messages over a queue.

Lee:

AWS offers such a queue service known as SQS.

Lee:

Using SQS, you can assign permissions to insert entries into the queue

Lee:

or remove entries from the queue.

Lee:

In our example, let's assume that service A has to insert messages

Lee:

into the queue, and the messages are read off the queue by service B.

Lee:

So both service A and service B need access to this queue, but the two

Lee:

services need different permissions.

Lee:

Service A needs to insert messages into the queue, but it doesn't need to be

Lee:

able to read messages from the queue.

Lee:

Service B needs to read messages from the queue, but not insert them into the queue.

Lee:

A simplistic implementation of the security for this queue would be to

Lee:

grant full access to the queue to both service A and service B, and probably any

Lee:

other component within the application.

Lee:

After all, nobody but service A would ever attempt to write a message into the

Lee:

queue, so why restrict them from trying?

Lee:

And no other service, but service B would ever try to remove a message from the

Lee:

queue, so why prevent them from doing so?

Lee:

But what happens if another service, let's say service C,

Lee:

is deployed with a bug in it.

Lee:

As a result of the bug service C starts writing messages into the

Lee:

queue it ist supposed to be using?

Lee:

You now have a rogue service, service C, sending messages to service B.

Lee:

This will likely cause service B to malfunction.

Lee:

Now, let's assume the service C didn't simply have a bug, but

Lee:

let's assume it had malware in it.

Lee:

Service C could now maliciously attack service B by writing

Lee:

messages into the queue that could cause service B to malfunction.

Lee:

So either because of an accidental bug or because of some bad actor attack,

Lee:

service C is suddenly causing service B to fail simply because service C was

Lee:

allowed to write into a queue that had absolutely no business to write into.

Lee:

Using the principle of least privilege, you would not let this happen.

Lee:

You would not leave the queue open to any service in the application to access.

Lee:

Instead, you would put a more detailed security policy in place and make it

Lee:

so only service A could write messages into the queue and only service B

Lee:

could read messages from the queue.

Lee:

If this security policy was in place when service C went rogue, it could

Lee:

attempt to write bogus messages into the queue, but it would fail because

Lee:

it didn't have the right permissions.

Lee:

Service C would still be failing, but it would not also bring down B with it.

Lee:

The principle of least privilege is designed to help reduce their risk

Lee:

from this sort of problem, and reduce bad actor attack vector possibilities.

Lee:

The principle of least privilege would require setting specific

Lee:

itemized permissions for all services, resources, and systems, and disallow

Lee:

any non-needed actions from occurring.

Lee:

By locking down the queue, you remove a failure mode of the application

Lee:

and remove a potential bad actor attack vector at the same time.

Lee:

This is the value of the principle of least privilege.

Lee:

Thank you for listening to Tech Tapas Tuesday.

Lee:

Tech Tapas is short topic, mini episodes on a technology topic of interest.

Lee:

We release them occasionally on Tuesdays on the Modern Digital Business Podcast.

Lee:

To make sure you get every new episode when they become available,

Lee:

click subscribe into your favorite podcast player, or go to mdb.fm/listen

Lee:

or go to leeatchison.com.

Lee:

Thank you for listening and welcome to the modern world of