Who is responsible for the Firewall

pts.
Tags:
Cabling
Firewalls
Forensics
Hubs
Incident response
Intrusion management
Network protocols
Routers
Security
Switches
VPN
Wireless
Our information Security department is different from the network group. Currently, we have Check Point firewalls running on Nokia boxes (IPSO image). The Network group handles the installation, upgrade, routing and IP address specification etc on the firewalls, while Information Security writes the rules. The problem is that almost all trouble shooting involves the two groups. For instance, in a session that involves VPN tunnels, Information Security will not be able to perform such simple but pertinent task of deleting and reestablishing a specific VPN tunnel as they would not have the right to do so. What have you seen in the industry? Should the firewall responsibility be split between two groups? If not, who should be responsible for the firewalls ? Information Security or the LAN/WAN group?

Answer Wiki

Thanks. We'll let you know when a new response is added.

Hello,

Welcome to the world of corporate politics! Your not alone on this. Many large corporations with compartmentized IT groups wrestle with this same delima as tasks are deligated with the idea of maintaining a system of checks and balances. Corporate does not want to give too much power to any one group. Unfortunatley in the IT ‘real world’ many routine tasks will overlap between the various groups causing a bottle neck to get things done. Kind of like the machine shop where the operator has to call the electrician because the machine came unplugged and to plug it back in falls outside the operators job description. Talk about waste in a world where companies are trying to go lean.

Logically I would have the network team’s responsibility go as far as installing the firewall and maintaining connectivity and turn all administrative tasks over to the Security team since they ultimatley are the ones in charge of writing rules, enforcing policy and serving user requests. But that’s just me!

Good luck!

Discuss This Question: 10  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

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
  • Kbrugnani
    Seems like too many hands in the pot however in my opinion the LAN/WAN group should be in charge of a firewall along with the routers and switches. Fortunately I am in control of everything and I do not have to worry about someone not being around when it comes time to troubleshoot a problem. Therefore, Security writing the rules should just be the informant, analysis, and tester of the written rules. In the past though I have had issue with Check Point blocking network connections and other VPN/Remote connections. Mainly the Check Point client where i'd have to disable the Check Point service. Well good luck hopefully something can change for you.
    0 pointsBadges:
    report
  • Sonyfreek
    In our group, we make the rules, we enforce the rules, we maintain the systems. However we are also like the last poster; we are both the Information Assurance/Security department as well as the network engineers. The way DoD wants it to be done, and the way the CISSP recommends it, you should have the functions separated for the checks and balances. Otherwise, it's like having the chicken guarding the hen house. However, I think that you could reasonably discuss having the IS folks make the rules, but providing them to the maintainers to write. They should have full audit capability of them to ensure that they are, in fact, being set and enforced. That would provide your least privilege and separation of duties. Sincerely, SF
    0 pointsBadges:
    report
  • Kzander
    Firewall security should not be split we tried it and doing so just made getting access right and setups take longer than they should. We ended up allocating a specific per not a group to be primary for the firewall, with cross education to both other groups so that there was more than one person who knows how to configure install and setup the firewall secutiyies and accesses.
    0 pointsBadges:
    report
  • Dollface
    We have servers on our network that were installed by our head office, which we have limited access to. We cannot add new users to these servers, or configure existing ones. This creates a big problem when we have to contact them to do a job that would take us five minutes, but it might take days or weeks??? to accomplish. Considering you are all on the same team I don't see the sense in locking one group out. It just creates an environment of innefficiency, and ultimately mistakes will be made. Just my two cents from someone who is frustrated that I am unable to do my job to the fullest extent.
    0 pointsBadges:
    report
  • Larrythethird
    We have it split and it causes grief constantly. The security group and the network group don't always work the same hours. The network group covers business hours but the security group basically works after hours. It can be real fun trying to get a change enabled for a new business process without prior knowledge. But then new business processes should be planned well in advance, SURE! We've only had to do emergency changes twice so far this month. But it is only the tenth of the month.
    0 pointsBadges:
    report
  • Mortree
    Usually splits like you described are designed to produce EXACTLY the effect you describe. It is known as security by inefficiency. The idea being that no work or change can proceed fast enough to escape full inspection. Your system works OK but probably needs a couple more groups involved to slow it down some more. Of course such thinking is usually imposed by managers with a secret agenda of trying to keep up with changes without visibly seeming to struggle or ask "stupid" questions. In reality if you want security and efficiency without sparing the egos of managers, your network group should do all actual implementation and troubleshooting. Your security groups should write policy, model general access rules and audit work done by the network group. But for serious control and to prevent "oops!" errors, all changes should go through a joint change control group first with security having veto power. Also emergency troubleshooting should be monitored by at least one secure group memeber and the implemented results immediately reviewed by a mini-change control group for temporary (24-48-72 hour) approval. The idea of change control being that it not only works but serious consideration given to security impacts from several viewpoints.
    0 pointsBadges:
    report
  • sari2006
    Hi.. In our organization each box based on its operation belongs to its own group.. Switches, routers ..etc belongs to network group. Firewalls, proxies...etc belongs to security group. by this in any failure only one group will be responsible to identify it.
    0 pointsBadges:
    report
  • Celtic
    Hello, In my industry (I'm an information security expert) I've seen 100% of the responsibility over a certain Firewall given to a single person/group. The Firewall responsibility should not be split between two groups, for it would always cause those "diagnostics bottlenecks" you've mentioned. As a thumb-rule, There should always be a "troubleshooting guy/group" (preferbly from the Information Security departement) who can access all the equipment and help solve problems as fast as possible. Hope I helped...
    0 pointsBadges:
    report
  • AlchemistTheGREAT
    Hi Muneanya, The split you mentioned is common practice in most large organizations (banks, multinational companies, etc.) and it actually makes sense. Security group's job description is to be sceptic and check if anything causes a security breach/invulnerability. Networks, on the other hand, always try to keep the connectivity up. Seems like inefficient, and it will be inefficient unless complemented by another component; please read on. What such organizations need are automated monitoring/management solutions that pinpoint the root cause and notify the related group of the issue. If you choose an integrable solution (not a cheap point solution) you may even link the infrastructure components to business processes and be notified of what's being impacted. Therefore, the split is normal (for a large enterprise) and it should be there to 'distribute the risk' (not too much authority in one hand) but the people problem (blame storming and finger pointing at worst, lack of coordination and wasted time in diagnosis at best) must be addressed by an automation suite. Message me in private if it makes sense to you and would like further advice. Regards. Alchemist
    0 pointsBadges:
    report
  • NetTech21
    I have been exposed to both schools of thought. I have seen both function with suprisingly excellent results. Once you get past the multiple group theory and buckle down to ensuring that it functions in a manner that will give the business a solution that they feel comfortable with while maintaining a high level of security to ensure longevity, both groups will enjoy the interaction. After being exposed to this type of environment, I found it difficult, yet not impossible, to return to a shop that is single grouped and handles all of the IT duties. I do however miss the ability to propose and have scrutinized ideas that from my mindset were good, yet proven to fall short as others questioned all aspects of my proposal. Keep working at it. It may surprise you what you get from the experience.
    0 pointsBadges:
    report

Forgot Password

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

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

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

Thanks! We'll email you when relevant content is added and updated.

Following