authentication, least privilege, and zero trust

When we are discussing “network security” phrases like “authentication”, “least privilege”, and “zero trust” tend to come up. The three terms are related, and can be easily confused.

I’ve been in “I.T.” for a while (the late 1980’s) – I’ve gone from an “in the field professional” to “network technician” to “the computer guy” and now as a “white bearded instructor.”

Occasionally I’ve listened to other “I.T. professionals” struggle trying to explain the above concepts – and as I mentioned, they are easy to confuse.

Part of my job was teaching “network security” BEFORE this whole “cyber-security” thing became a buzzword. I’ve also had the luxury of “time” as well as the opportunity/obligation to explain the concepts to “non I.T. professionals” in “non technical jargon.”

With that said, I’m sure I will get something not 100% correct. The terms are not carved in stone – and “marketing speak” can change usage. SO in generic, non-technical jargon, here we go …

Security

First, security as a concept is always an illusion. No I’m not being pessimistic – as human beings we can never be 100% secure because it is simply not possible to have 100% of the “essential information.”

SO we talk in terms of “risk” and “vulnerabilities.” From a practical point of view we have a “sliding scale” with “convenience and usability” on one end and “security” on the other. e.g. “something” that is “convenient” and “easy to use”, isn’t going to be “secure.” If we enclose the “something” in a steel cage, surround the steel cage with concrete, and bury the concrete block 100 feet in the ground, it is much more “secure” – but almost impossible to use.

All of which means that trying to make a “something” usable and reasonably secure requires some tradeoffs.

Computer Network Security

Securing a “computer” used to mean “locking the doors of the computer room.” The whole idea of “remote access” obviously requires a means of accessing the computer remotely — which is “computer networking” in a nutshell.

The “physical” part of computer networking isn’t fundamentally different from the telegraph. Dots and dashes sent over the wire from one “operator” to another have been replaced with high and low voltages representing 1’s and 0’s and “encapsulated data” arranged in frames/packets forwarded from one router to another — but it is still about sending a “message” from one point to another.

With the old telegraph the service was easy to disrupt – just cut the wire (a 19th century “denial of service” attack). Security of the telegraph message involved trusting the telegraph operators OR sending an “encrypted message” that the legitimate recipient of the message could “un-encrypt.”

Modern computer networking approached the “message security” problem in the same way. The “message” (i.e. “data”) must be secured so that only the legitimate recipients have access.

There are a multitude of possible modern technological solutions – which is obviously why “network administration” and “cyber-security” have become career fields — so I’m not going into specific technologies here.

The “generic” method starts with “authentication” of the “recipient” (i.e. “user”).

Authentication

Our (imaginary) 19th Century telegraph operator didn’t have a lot of available options to verify someone was who they said they were. The operator might receive a message and then have to wait for someone to come to the telegraph office and ask for the message.

If our operator in New Orleans receives a message for “Mr Smith from Chicago” – he has to wait until someone comes in asking for a telegraph for “Mr Smith from Chicago.” Of course the operator had no way of verifying that the person asking for the message was ACTUALLY “Mr Smith from Chicago” and not “Mr Jones from Atlanta” who was stealing the message.

In modern computer networking this problem is what we call “authentication.”

If our imaginary telegraph included a message to the operator that “Mr Smith from Chicago” would be wearing a blue suit, is 6 feet tall, and will spit on the ground and turn around 3 times after asking for the message — then our operator has a method of verifying/”identifying” “Mr Smith from Chicago” and then “authenticating” him as the legitimate recipient.

Least Privilege

For the next concept we will leave the telegraph behind – and imagine we are going to a “popular music concert.”

Imagine that we have purchased tickets to see “big name act” and the concert promoters are holding our tickets at the “will call” window.

Our imaginary concert has multiple levels of seating – some seats close to the stage, some seats further away, some “seats” involve sitting on a grassy hill, and some “seats” are “all access Very Important Person.”

On the day of the concert we go to the “will call” window and present our identification (e.g. drivers license, state issued ID card, credit card, etc) – the friendly attendant examines our individual identification (i.e. we get “authenticated”) and then gives us each a “concert access pass” on a lanyard (1 each) that we are supposed to hang around our necks.

Next we go to the arena gate and present our “pass” to the friendly security guard. The guard examines the pass and allows us access BASED on the pass.

Personally I dislike large crowds – so MY “pass” only gives me access to the grassy area far away from the stage. Someone else might love dancing in the crowd all night, so their “pass” gives them access to the area much closer to the stage (where no one sill sit down all night). If “big recording executive” shows up, their “pass” might give them access to the entire facility.

Distinguishing what we are allowed to do/where we are allowed to go is called “authorization.”

First we got “authenticated” and then we were giving a certain level of “authorized” access.

Now, assume that I get lonely sitting up there on the hill – and try to sneak down to the floor level seats where all the cool kids are dancing. If the venue provider has some “no nonsense, shaved head” security guards controlling access to the “cool kids” area – then those guards (inside the venue) will check my pass and deny me entry.

That concept of “only allowing ‘pass holders’ to go/do specifically where/what they are authorized to go/do” could be called “least privilege.”

Notice that ensuring “least privilege” takes some additional planning on the part of the “venue provider.”

First we authenticate users, then we authorize users to do something. “Least privilege” is attained when users can ONLY do what they NEED to do based on an assessment of their “required duties.”

Zero Trust

We come back around to the idea that “security” is a process and not an “end product” with the “new” idea of “zero trust.” ” Well, “new” as in “increased in popularity.”

Experienced “network security professionals” will often talk about “assuming that the network has been compromised.” This “assumption of breach” is really what “zero trust” is concerned.

It might sound pessimistic to “assume a network breach” – but it implies that we need to be looking for “intruders” INSIDE the area that we have secured.

Imagine a “secret agent movie” where the “secret agent” infiltrates the “super villain’s” lair by breaching the perimeter defense, then enters the main house through the roof. Since the “super villain” is having a big party for some reason, out “secret agent” puts on a tuxedo and pretends to be a party guest.

Of course the super villain’s “henchmen” aren’t looking for intruders INSIDE the mansion that look like party guests – so the “secret agent” is free to collect/gather intelligence about the super villain’s master plan and escape without notice.

OR to extend the “concert” analogy – the security guards aren’t checking “passes” of individuals within the “VIP area.” If someone steals/impersonates a “VIP pass” then they are free to move around the “VIP area.”

The simplest method for an “attacker” would be to acquire a “lower access” pass, and then try to get a “higher level” pass

Again – we start off with good authentication, have established least privilege, and the next step is checking users privileges each time they try to do ANYTHING.

In the “concert” analogy, the “user pass” grants access to a specific area. BUT we are only checking “user credentials” when they try to move from one area to another. To achieve “zero trust” we need to do all of the above AND we assume that there has been a security breach – so we are checking “passes” on a continual basis.

This is where the distinction between “authentication and least privilege” and “zero trust” can be hard to perceive.

e.g. In our concert analogy – imagine that there is a “private bar” in the VIP area. If we ASSUME that a user should have access to the “private bar” because they are in the VIP area, that is NOT “zero trust.” If users have to authenticate themselves each time they go to the private bar – then that could be “zero trust.” We are guarding against the possibility that someone managed to breach the other security measures.

Eternal vigilance

If you have heard of “AAA” in regards to security – we have talked about the first two “A’s” (“Authentication”, and “Authorization”).

Along with all of the above – we also need “auditing.”

First we authenticate a user, THEN the user gets authorized to do something, and THEN we keep track of what the user does while they are in the system – which is usually called “auditing”.

Of course what actions we will choose to “audit” requires some planning. If we audit EVERYTHING – then we will be swamped by “ordinary event” data. The “best practice” becomes “auditing” for the “unusual”/failure.

e.g. if it is “normal” for users to login between the hours of 7:00AM and 6:00PM and we start seeing a lot of “failed login attempts” at 10:00PM – that probably means someone is doing something they shouldn’t.

Deciding what you need to audit, how to gather the data, and where/when/how to analyze that data is a primary function of (what gets called) “cyber-security.”

“Security” is always best thought of as a “process” not an “end state.” Something like “zero trust” requires constant authorization of users – ideally against multiple forms of authentication.

Ideally intruders will be prevented from entering, BUT finding/detecting intrusion becomes essential.

HOW to specifically achieve any of the above becomes a “it depends” situation requiring in depth analysis. Any plan is better than no planning at all, but the best plan will be tested and re-evaluated on a regular basis — which is obviously beyond the scope of this little story …


Posted

in

, ,

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *