Modern security management strategy requires security separation of duties

Contributor Matthew Pascucci argues that enterprises need security separation of duties to ensure an effective, modern security management strategy.

Over the past few years, information security has become a top-level concern to enterprise senior management. Many

organizations by now have created information security departments to secure themselves from the threats they’re facing, but in today’s environment, it’s no longer enough. Hence the reasons why a paradigm shift is needed regarding the ways security departments are being structured. No longer should one department manage security from cradle to grave.

There are only two ways that companies end up doing this: They realize the benefits of having separation of duties within the department themselves, or are told to by auditors.

Having two departments share the information security burden is an ideology that’s starting to gain traction; especially in the financial sector due to regulatory mandates like the Sarbanes-Oxley Act (SOX) and Gramm-Leach Bliley Act (GLBA). The idea of having separate roles for those monitoring security incidents and those implementing and acting on security incidents is a shift in thinking. Most security departments are configured as a one-stop security shop, handling everything from strategy, policy, configuration and remediation, but this is broad swath of duties and responsibilities can be lost or purposely overlooked.

As an example, in most enterprises the engineer making a firewall change is also the one reviewing the firewall metrics for unauthorized changes. What if the firewall administrator wanted to hide something? How would anyone ever find out? This is where the separation of duties comes in to focus on the responsibilities of tasks within security.  Creating an information security team in this structure allows for dedicated resources performing security from an operation and monitoring standpoint. This paradigm encourages a focused approach to each group and allows for the resources to have dedicated responsibilities. This means the security operations staff is busy with engineering and incidents and the monitoring group is looking for breaches.

To that end, a better model is one in which engineers in an IT operations group would make configuration changes, and then information security analysts in the information security monitoring and management group would monitor the environment, analyze key data and make recommendations on changes and updates. Let’s review each group’s duties in detail.

The operation group would be responsible for the implementation of new security technology and its day-to-day use. Its main focus would be responding to security incidents and hardening systems on an operational level, as well as the remediation of security events and managing technology that helps secure the company proactively. This team should also have rights to investigate issues on equipment, verify configurations are setup properly, and assist with the overall security lifecycle of the infrastructure. This team would manage the configuration and implementation of the network and systems, while managing devices that help protect the perimeter and internal proactively. Some technologies that would fall under the auspices of this group are firewalls, IPS, NAC, WAF, etc.

The monitoring group, on the other hand, should be the security watchers. This group’s main function would be to look for security incidents and vulnerabilities. This group should actively monitor the infrastructure for potential issues and escalate them to the IT operations group as incidents. This team should have read-only permissions to many systems, but shouldn't have the rights to make changes. Its job should be to review the infrastructure, identify potential incidents and alert those with the permissions to take action on them. This team’s main concerns would be the review of the network for breaches, either externally or internally. Technologies that may be housed in this department would include those that support the mission of monitoring and security oversight, such as SIEM, DLP, identity management, vulnerability management, and the like.

With the implementation of a security separation of duties involving two distinct groups managing an enterprise’s information security posture, there may be a feeling of overlap. Both teams will have some access to the majority of the systems housed in each other’s department, but one department will be responsible for certain actions of the tool.

An example of such technology sharing would involve the use of the SIEM. The monitoring group would want to use it to proactively search for and identify potential security incidents, while the operations team might use its logs to research an incident. Both would have access to the tool, but use it for different purposes. Having one team searching for and alerting on events would allow the other to focus on hardening and implementing better security. When the security incident management lifecycle is left solely to one group, issues can easily be overlooked and hence gaps in a security program can result. Having the two teams work in tandem and reporting to different branches of the organization allows for the strongest security posture in an organization. Both groups keep the other honest, and work together to secure the network.

There can be some tension when establishing this sort of organizational change or even simply refining separation of duties between the groups. Many employees are accustomed to the standard structure of an all-in-one department and are not open to change. There are only two ways that companies end up doing this: They realize the benefits of having separation of duties within the department themselves, or are told to by auditors. 

Once the decision is made to separate the groups, there needs to be a Responsibility Assignment Matrix (RACI) that is used to identify the roles and responsibilities between the two groups. This will clarify which team is ultimately responsible for certain activities and systems. Most importantly, even though the two teams are separate, they should not be isolated as to what each other’s purpose is. They should have weekly status meetings so each team is aware of what’s occurring on the other side. Just because they’re not in the same groups, doesn’t mean they can’t work together.

About the author:
Matthew Pascucci has more than 10 years of experience in IT and is currently an information security analyst in the financial sector. He holds multiple certifications and is actively involved with InfraGard to help educate others in information security. You can follow his blog at www.frontlinesentinel.com or on Twitter at FrntLineSentneL.

This was first published in November 2011

Dig deeper on Business Management: Security Support and Executive Communications

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close