Ask the Expert

How should security and networking groups manage the firewall?

Our information security department is different from the network department. The network department handles the installation, upgrade, routing and IP address specifications on the firewalls, while our information security department writes the rules. The problem is this: almost all troubleshooting involves the two groups. For example, in a session that involves VPN tunnels, the information security group can not perform a simple but pertinent task like deleting and reestablishing a specific VPN tunnel, since they would not have the right to do so. What have you seen in the industry? Should the firewall responsibility be split between the two groups? If not, which should be responsible for the firewalls -- the information security team or the networking department?

    Requires Free Membership to View

I frequently see this confusion and bumping of heads in the industry. The good thing is that your company is actually trying to do the right thing by properly separating the network and security tasks. It also sounds like you have permissions locked down pretty tightly, which just warms my heart.

Firewall responsibility should fall within the security group, as should all other security devices. The security group should configure, test and maintain them. But life is not always that black and white. As devices take on an increasing number of functions, networking and security tasks are becoming more entwined than before.

Networking people are usually focused on making sure the company's resources are constantly up and running. Sometimes security interferes here, but for the right reasons. If you are having difficulties designating networking and security tasks when troubleshooting, then the networking people should diagnose the issue. If it is determined that a security setting is causing the problem, then the security people have to decide whether the rule or configuration has to stay in place or not. To get through the troubleshooting process, the networking people may discover the issue, but they should not make any changes that affect security.

Many times, what is functional for an enterprise conflicts with what is secure. When this dilemma occurs, a high-level manager should make the call. I have been in environments, for example, where management allows external IM to come and go through their perimeter devices. Management was made fully aware of the risks, and they accepted these risks in writing. Many other environments, however, will not allow external IM servers because management has decided that there is no business purpose for it and that they should avoid any risks. These decisions should all be a part of your company policies.

A bad habit that occurs in many companies is that people in the networking department might, for example, modify access controls lists, or some other security settings, because they think that they understand it enough to make these judgments. What many networking people do not realize is that this is not their job, and they do not want to be held liable for such decisions. There have been cases where a network engineer had changed an access control list, allowing sensitive data to leak through the newly opened port. Sometimes these decisions have such dramatic results that the company can get sued, put in the headlines and actually thrown out of business. Networking people should understand the liability and responsibility that comes along with making security decisions.

Networking and security teams should work together, but with structured boundaries. Security changes should be approved, tested and documented. If there are questions or discrepancies, review the policies and standards, and if they do not clear up any confusion, take the issue to higher management.

More information:

  • Learn more about when security and networking groups should be kept separate.
  • Find your best options for handling a segregation of duties.
  • This was first published in February 2007

    There are Comments. Add yours.

     
    TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

    REGISTER or login:

    Forgot Password?
    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
    Sort by: OldestNewest

    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: