February 17, 2011

When who you are isn't enough

I took a journalism course when I was in college and I remember the professor telling us that every event had an identity that was defined by five elements (Who, What, Where, When and How) and that we needed to include all of these elements in every article we wrote about the event. The same is true of the people that we allow on our networks; they also have an identity that includes their name (who), what type of device are they using (what), where they are logging in from (where), the day of the week and the time of day (when), and how they authenticated onto the network (how). Unlike journalism students, network administrators seem to have been taught that they only have to worry about who is asking to access the network. The username and password validates who the user is, but the what, where, when, and how are generally ignored. As is often the case when we are making decisions with limited information, the results can be both embarrassing and costly.

If a professor at a local college authenticates successfully onto the network, can we feel secure giving him full faculty access to the servers holding the test and grades databases? We really need more information before we make a decision. If he is logging in from his office at 1:00 PM on Monday then we can feel reasonably comfortable giving him full faculty access. On the other hand, if he is logging in from a student dorm room on Saturday at midnight, common sense would lead us to question either his identity or his judgment. In either case we probably don’t want to give whoever it is access to the servers where the tests and grades are stored.

It seems pretty obvious that considering authenticated user (user name and password), location and time before granting access provides better security then relying entirely on the user name and password. Each element we add increases not only security but also authorization options. For example we might have a rule that restricts access to servers that contain sensitive information if the user authenticates from a wireless network but allows access to all other networked resources. Your PCI compliance auditor will probably like that rule.

Evaluating each element opens up the potential to implement very fine grained access control policies.

• Who – username and password can be tied to role in the organization and used as a basis for role based access control (RBAC)
• What – IP phones, Tablets, Servers, PCs and Smart Phones can all have different access policies
• Where – Accessing the network from secure or non-secure locations can result in different authorizations
• When – Working and non-working hours can have different access
• How – Different authentication methods can result in different levels of trust. We trust 802.1X with biometric authentication more then we trust MAC based authentication

The best part is that these elements can be combined into a single policy. For example: You can access the cardholder data environment if:

1) You authenticate using 802.1x – and
2) you are not connecting from a wireless network – and
3) it is during normal working hours – and
4) you are using your assigned computer

This may seem like an extreme example but it would have gone a long way toward preventing many recent data compromises.

The bottom line is; the more information we evaluate before deciding what access level to grant a user, the better our security is going to be. My journalism professor would be proud. I finally used Who, What, When, Where and How in the same article.

About The Contributor:
Extreme Marketing Team

See My Other Posts