Taking a toll: Separation of duties...or not.

Security analysts often find themselves turning a blind eye to another organization's security issues in order to have their own needs met. At other times, we just appreciate the irony when we're told about the security process, and how the organization's representative just violated it to get their job done. Here's a recent example:

A co-worker recently signed up for the local toll road's quick pass through system. This is more arduous than it needs to be, and after a number of rounds with them due to process issues such as missing activation IDs, incorrect instructions, documentation that didn't match the process documentation, and missing emails, he found that he needed an activation PIN that should have been sent via email, but wasn't, and called for a third time.

The organization in question is carefully set up so that individuals don't see both your account number and your PIN at the same time. If a support team member prints your PIN and address to be mailed, another department will mail it without knowing your account number.

This sounds pretty reasonable, and should be workable. It even ensures a reasonable amount of safety to the customer - or should. Unless, of course, the PIN is sent by email, and the provider has DNS issues and can't resolve your well known TLD. That makes CSRs get creative.

The service representative did the right customer service thing, and the wrong separation of duty thing: he walked to the other department, got the paper from the printer, and read the PIN over the phone. No controls prevented it, making the separation only meaningful to those who wish to follow the rules.

Not exactly effective compartmentalization - but it worked in the customer's favor this time.

This is a useful case to remind us that our carefully built process requires checks and monitoring. Simply relying on processes without validating them and verifying that they aren't being violated can be worse than knowing that no process exists - you're left with a false sense of security.

The co-worker? He found out that the pass system charges a maintenance fee every month in addition to the tolls and the money kept by the toll system to "charge" his account, and is considering switching to the alternate system available in the area.

Creative Commons image credit billjacobus1

Lessons in adaptability: a TSA screener's response to the MacBook Air

Most IT people have probably seen a commercial for the MacBook Air, even if we haven't seen one in person. It's thin, it doesn't have a standard optical drive, and may not even have a spinning hard drive if it has the SSD option.

A post on Wide Awake Developers offers a good reminder about awareness and security training. The TSA employees who were faced with a MacBook Air didn't recognize it as a laptop - according to the post, they called it a "device", and delayed the poster long enough to make him miss his flight. The good news is that the TSA agents did eventually ask for their normal "boot the machine and demonstrate an application" method of validating that it is a computer. A perfect process? No, but at least they eventually got through to it.

What's the lesson? It's a simple one: don't forget to teach adaptability and to have a method for dealing with unrecognized issues and technologies when you're building a security system. Adaptable security models are more likely to catch issues, and can prevent process breakdowns that can cost money or response time. Every system should have a fall through catch-all - if something doesn't fit the expected norms, a process needs to take over that will handle the event.

There's one more lesson to be learned thanks to the MacBook Air - don't lose it. Steven Levy demonstrates how easy it is to lose a small device, and with a decent size drive in it, an unencrypted MacBook or other small, executive friendly device can expose a large amount of data.

Creative Commons licensed Flickr photo credit to Marcin Wichary.