Thinking Security: Who is That?

 Author(s): , Posted on March 11th, 2016

This is the 14th blog in a series about security and how security is about how you think.

In the last blog, I talked about the seven goals of security. Each of the next seven blogs will take one of those goals and dive deeper to explore how we “think security” with each of them. This blog is about the first goal: identity and authentication.

This is one of the more obvious goals of security because we identify and authenticate others and we are identified and authenticated every day of our lives. When we buy items, we are identified and authenticated. When we talk to each other, we identify and authenticate others.

Where this issue impacts security is that we want to identify and authenticate others to the level that we want them to, yet not be identified and authenticated when we don’t want to be. In most security scenarios, we want to identify every “action” (an event that has happened) back to an “actor” (the representative person or service) that is performing that operation. We may want to care about every identity of every person who does something or we may also want to allow anonymous access – it’s up to the nature of the service that we provide or want to connect to that will make this decision. The service may also want more than one method of authentication per identity so that there is a higher level of assurance that the person/actor is who they say that they are.

Let’s show some scenarios to illustrate this thinking:

  • When we access a website, our identity isn’t shown – most websites allow anonymous access to retrieve any information – so there is no identity and therefore, no authentication of actors to a website. Some do offer a username and password if you sign up, so that frequent settings and content is saved for you. In this scenario, there is very little authentication other than being able to specify an email address which you can access. Authentication is that you can receive an email and click on the special link that they send to complete the process.
    But what about what Google does with saved searches – they take your IP address to be your identity. Is this really a valid way of identifying users? If it is fixed, then it may be, but many computer systems can get a different IP address when they connect to the network. And how do you validate an IP address?
  • When I come to work each morning, I swipe my Unisys badge onto the door panel to get into the building. This “identity” isn’t an email address (but it is tied to my Unisys ID number). It’s validated because the identity was given to me by Unisys (as a badge) and I’m just presenting it back to them in order to gain access. It’s validated by Unisys because they gave it to me.
  • In other cases, some services may require “two-factor authentication” – having the same identity validated through by more than one authenticator. For example, I just rented a car and had to show my driver’s license (validated by the state of Pennsylvania) and a major credit card (validated by a large financial institution). Therefore, the car company felt that my identity was validated because they were letting me borrow their car.

Now one person can have multiple “identities” (and still not be crazy). Think of it this way – you may have a work email address, a home email address, and maybe another address (like a school or club address). Each one is an “identity.”

But how do we validate and trust identity? It may be direct trust (I know that’s my neighbor Pete because I see him every day), or I may trust an external identity (for example, with a driver’s license, I’m trusting that the driver’s license is valid and actually from the state of Pennsylvania). In the case of my Unisys badge, it’s implicitly trusted because I received it from the company (actor) who which I’m presenting it to.

These processes of identification and authentication become more complicated when we deal with computer systems. Who we trust is tougher to declare. The system that we use may already implicitly trust entities because it makes the computer system easier to use (for example, look at Internet Explorer’s Trusted Root Certification Authorities list – it will scare you). How do we NOT trust someone?   We also have to define which identities that we will honor very specifically because more and more, these are external identities (Facebook logins, Twitter handles, and external email addresses) rather than very local identities (usernames and passwords, badges) that are managed very easily.

With computer systems, identities are easier to forge because we can try identities easier (brute force attacks) usually without having to hide ourselves. That’s why logging of identification and authentication attacks is crucial to determining if there is a problem or not.

Identity and authentication are one of the primary goals of security, because identifying who or what is performing or attempting to perform an operation is an important part of the other goals of security. Having a record of the identity and the authentication is also extremely important into forensic analysis of what has happened.

It’s not rocket science – we do identification and authentication every day – but it’s how you think about it that makes it a key mechanism of the security mindset. It’s about how you think about identity, authentication, and eventually trust that makes the world secure.

Tags: , ,


About the Author

Mike Kain is a consulting engineer and security architect for the ClearPath MCP environment and has held various technical leadership positions during his 30 years of experience at Unisys. Read all Posts





«Surviving the Analog Apocalypse

Service Management from a Personal Perspective »






Back To Top
Copyright © Unisys 2017

We use cookies on this site. By using this site, you agree to our use of cookies. To change or learn more, see our Privacy Notice.