Saturday, January 16, 2010

Security Team Permissions

Every so often I receive questions from blog readers. The latest centered on the following question:

What level and extent should a security team and investigators be allowed to operate without having to ask for permission?

This is an excellent question, and as with most issues of authority it depends on the organization, its history, culture, purpose, and people.

From the perspective of the security team, I tend to want as much access as is required to determine the security state of an asset. That translates into being able to access or discover evidence as quickly and independently as possible, preferably in a way that involves no human intervention aside from the query by the security team. When the security analyst can retrieve the information needed to make a decision without asking for human permission or assistance, I call that self-reliant security operations. Anything short of that situation is suboptimal but not uncommon.

Simultaneously, I want the least amount of access needed to do the work. If the security team can get what it needs with a read-only mechanism, so much the better. I actively avoid powerful or administrative accounts. Possessing such accounts is usually an invitation to being blamed for a problem.

Assume then that there is a situation where the security team believes it needs a certain elevated level of access in order to do its mission. In my experience, it is rare to obtain that permission by making some sort of intellectual or process-oriented argument. Rather, the security team should make a plan and justify the need for such access, but wait for an intrusion to occur that demonstrates why elevated access would improve the incident detection and response process.

In many cases, management with authority to grant or expedite granting access lacks the focus or mental environment ready to think about making changes until an incident rocks their world. Once management is ready to devote attention to a problem, they are often eager to hear of changes that would improve the situation. At that point one should make a case for the new capability. We see this pattern repeatedly in high-profile security cases; airline travel is the most obvious.

Aside from waiting for a catastrophe, the next-best option is to collect some sort of metric that shows how the current suboptimal state of affairs should be unacceptable to management. If you could show a substantial decrease in response time, an increase in capability, a decrease in cost, etc., you might be able to convince management to make a change without resorting to an incident scenario. This second option is less likely to work than the disaster method, but at the very least it does lay useful groundwork prior to an incident.

2 comments:

jeff said...

Alternatively to waiting for an intrusion, often security teams are skilled troubleshooters. If they can find a broken system (dns misconfig, routing problem, etc) through their analysis this often builds the trust necessary to grant the elevated privs.

Joe said...

I agree. Nice post.

I also agree with Jeff. I've helped solve a number of issues. Perhaps more system and network admins need to learn the skill of problem investigation. It's not just a security skill.