A familiar refrain of any user that has dealt with IT security is "it wouldn't be security if it didn't get in the way." Even though that's exactly the point--to prevent certain users getting at certain things--to most users these processes are just nuisances to get around, making users feel like a mouse in a maze. An unfortunate consequence of these restrictions is the occasional user who gnaws through a wall to make a short cut to the cheese (or in this case bypass a security process to get access to an IT resource).
For example, at a large organization the manager of a development team designated Alice as the security POC for the team. The team needed access to a monthly report on a network share. Alice put this need into a request and sent it to Security to implement. Security replied that it should be done within 48 hours, and Alice promptly communicated this to her team.
Bob, a developer on the team, couldn't wait however. It wasn't an emergency; he just didn't like mazes.
Bob emailed someone he knew in Security (S1), complaining "I get an 'access denied' error when I try to open the monthly report." S1 forwarded this to S2, and S2 cc'd S3. Three security resources were then engaged to resolve what they regarded as a security issue. After some more back and forth over a couple hours, Bob got his access. To celebrate, Bob then emailed the entire development team to declare that everyone on the team now had access to the report, thanks to him. But this wasn't entire accurate, and I find three glaring problems with his approach:
- Efforts were duplicated. Bob's need to access the report was already covered by the request Alice sent earlier to Security, so it was probably already being worked on. Bob's separate request, however, engaged three additional Security personnel, meaning four Security people were all involved in the same effort. Also, the person who was working on Alice's request might have seen that Bob already had access, which might have thrown a red flag that would have taken yet more time and effort to sort out.
- Results were not validated. When Bob announced that the team now had access, he did not verify this first. So when the rest of the team tested their access, they found that actually, no, they still didn't have access. So they might have also contacted Security one-by-one to report that they should have access but didn't. Meanwhile, their Frustration-o-meter with Security (the team, the concept, and possibly Alice) would drift a little further into the red. At least Alice knows the value of the tenet "trust but verify."
- It wasn't an emergency! Why did Bob get three Security resources spun up to work on his access request when it was more of a "nice to have" than a "need it now" request? Even if it was an emergency, he should have gone to Alice first. Furthermore, why didn't the Security team push back a little and first ask Bob if, one, this was an urgent need, and two, if this was already in the request submitted by his team's security POC (Alice)?
The development team had a clear security request process in place, but it was ignored by both Bob and the Security team. Bypassing security processes can be wasteful and even dangerous, and by circumventing the security POC, the credibility and need of the position is undermined.
A formal security request process, if well thought-out and enforced by Management, offers several benefits to an organization: efficient use of resources, minimal duplicated efforts, trackable changes, and, most importantly, least privilege. The security POC can review, record, organize and translate user requests into technical deliverables, and by funneling user requests through a security POC, the Security team can focus on processing the request, rather than spending time trying to figure out what it is that the user is asking for.
But even the best-laid plans are for naught if Management does not enforce them. Because when the cat's away...
More...
08-25-2008
