Operationalizing Security

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?

Comments

[Michael Janke]

In our large (20,000 employee) enterprise, the model that we designed is essentially what you describe. We believe that it works.

In our model, the responsibility for designing, building, deploying and managing secure applications and systems lies with the operational manager of the technology. The security group sets standards, acts as consultants, advises, mentors and works closely with the operational units to ensure that the units have a reasonable security posture and are compliant with necessary standards, rules and laws.

The security group keeps us (in operations and design) informed of the threat landscape, advises operations on what they'll need to be doing a year or so from now, and keep tabs on the actual state of security within the operation units through internal security assessments, and system reviews. Security handles most incidents, with operations in a support role, but operations runs the security monitoring and detection technology.

In the event of a conflict between security & operations, the security group holds the trump card (executive persuasion), but rarely has to use it. The environment is collaborative enough, and both groups have enough of a sense for the other groups pain points, that persuasion is rarely necessary.

The operational entities, in turn, consult with the security group on any new implementations, ask advise on relative value of systems or technologies, but still assume ultimate responsibility for the implementation. But operations assumes responsibility knowing that security has a stake in the game and will back up operations in any eventuality.

I'd like to say that we paid a Burton consultant a couple hundred per hour to build the model for us, but we didn't. ;)

We simply decided that the persons implementing the technology are best able to ensure it's security.