Blogger: Trent Henry
Although friends and family would say otherwise, and tend to berate my penchant for sesquipedalianism (look that one up), I prefer to avoid a word as long as "operationalization."
However, we received an important question from a client lately: "What are the top security tasks that can be operationalized?" Put another way: "What tasks can be offloaded to network-, desktop-, or other operations groups?"
We've observed a trend over the last several years of enterprises moving certain day-to-day "security" functions to operational teams. This frees the security group to focus on more strategic matters, such as policies and architecture. It's a good management practice and creates natural separation among those who carry out tasks, those who provide oversight, and those who design controls. But what's the low-hanging fruit?
Foremost, here are some "operationalization litmus tests" for whether or not something might be handed to secops, netops, or desktop ops:
- Is it a repetitive task that is clearly spelled out in a process or procedure?
- Would operational execution of the tasks cause any violation of segregation of duties?
- Are there specific regulatory or contractual mandates stipulating who must do a piece of work?
- How high is the business risk in the area under consideration? The higher the risk, the more security oversight is warranted
Looking at common security tasks, here are some "best bets" for those to operationalize:
- 1st level help desk, including password reset and other credential handling
- Standard user account management
- Desktop patching
- Running standard vulnerability management infrastructure
- Firewall rule changes, if part of proper change control program with external oversight
- (possibly) Some degree of project management
- Security awareness and training execution (which might be handled by HR)
- Routine assessments (business unit, vendors, or others) that have been standardized (and "standardized" is an extremely important caveat, because such assessments might be compensating controls. For example, they might provide the monitoring of an outsource vendor's security program.)
On the flip side, here are "best bets" to retain in a Security architecture/strategy/program management team:
- Incident response (although ops might need to lend a hand)
- Future security architecture
- Policy
- Risk management and compliance monitoring
- Security awareness and training development
- Assessment program development and roll-up (create certification and accreditation [C&A] criteria, and aggregate organizational results)
- Interface with internal/external audit and higher-level risk management functions
Whether to shift/contain costs or keep security teams focused on more strategic functions, operationalization can be a legitimate, wise approach.
What are your experiences?
