EXPERT RESPONSE
This is a common struggle in organizations and it is usually driven by turf wars, politics, or just plain misunderstanding of the role of security within the organization. It also has to do with the culture of the environment.

I have worked with a HUGE corporation that follows what your IT and auditors laid out as the roles. IS just creates standards, policies, carries out risk assessments, and SUGGESTS how things should be implemented. The IS department monitors the compliance with the standards, but there is no real consequences if compliancy is not met. This corporation’s answer for this approach is that the culture of the environment would not accept security TELLING anyone how things should be secured. In my mind, that means that the corporation is just wasting money on having anyone in their security group at all if they are merely advisors who provides guidelines. This is like hiring a police staff for a city to protect the public, but they can only recommend safety procedures to the community and not enforce any laws.

The reason that the corporation I mentioned works in the model that they do is because they have a security officer who does not understand information security at all – that person is a purely business person and has no background or knowledge of technology or security at all and this is a great disservice to the organization as a whole.

In many environments a security team does not have the necessary skill set and scalability to configure and maintain each and every security mechanism in the enterprise. This is because so many things are security mechanisms; router ACLs, VPN software, user profiles, remote access servers, registry settings, mainframe access – basically every component on the network has some type of security responsibility, even if it just means that it is configured properly. This is why many organizations have their security staff create policies and standards and verify compliance through tools like Symantec ESM or implement Tripwire to keep track of changes on systems. Other organizations take on the structure where the security staff creates standards and implements them and maintains them. This model usually means that the security staff maintains firewall, IDS/IPS, and other blatant security devices and configurations, but not does not maintain all the servers, workstations, and such.

Pertaining to access control specifically the process should be:

1. Roles are created with the necessary rights and permissions assigned to the roles
2. A request to approve the addition of this user to a specific role (or changes to an existing one) is sent to the employee’s manager, or who has been delegated this approval responsibility.
   a. Request is done through e-mail or a web-based tool so that it is documented
3. An approval from the manager is stored centrally and e-mails go out to the network group to assign the new user to an already existing role(s), which means the user inherits the rights and permissions of the role(s).

You probably do not have an enterprise wide RBAC structure in place, but this is why more and more companies are moving to this type of access control. It reduces the confusion on what rights and permissions each and every user needs. But even if you do not have a RBAC in place, these are the steps of assigning rights and permissions – but in step 3 the security group would set the users’ permissions, rights, and initial password.

The reason that the manager (or someone is delegated this role) has to be involved in the approval of assigning rights and permissions is because regulations are requiring more and tighter accountability to activities within corporate environments. (The days of IT administrators assigning root or administrative rights here and there should be a thing in the past.)

In actuality neither the IT or security team should be deciding what access rights users should have, this is the responsibility of a management entity (data owner, manager, etc.) because they are ultimately responsible. The IT and security team are SUPPOSED to be the custodians and ensure that the protection level that a management entity has decided upon is enforced through implementing and maintaining security mechanisms. But in the commercial sector, environments and access control programs have not necessarily reached this maturity level – so we are back to your original questions, should IT or security assign security rights.

My answer is always that there should be a segregation of duties when it comes to network and security teams. I am including my response to another individual some months ago who asked about who should be involved in troubleshooting.

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.

But here is what most disturbs me in your message, which is the core of this debate but often missed.
“IT takes into consideration and implements at their discretion”

If you have a security team, you probably have a CISO or CSO, and this person should realize his/her head is on the chopping block. When a security breach takes place, the IT people will not be called to the carpet – the security staff will. In many environments when a company has a data leakage that is potentially damaging or devastating to the company – the security officer has to explain to the board of directors what happened, why, exposure ramifications, mitigation steps, and who will be fired.

In organizations that allow other business units to make security decisions, as you are describing here, have some type of risk waiver. This usually means that someone (usually a business person) signs some piece of paper indicating that they are taking on the risk that has been identified by the security team and the business unit will not allow implementation of the necessary countermeasure. This almost always equates to someone accepting some type of risk he in no way understands.

So, no matter if your organization has the security team do the implementation and managing of security devices and decisions or just do the monitoring of the effectiveness of the IT team to follow the standards – it is critical that it is not at ANYONE’S DISCRETION except management, the board, and the security officer. Security has the responsibility of protecting the company’s assets, so they should be making the rules and ensuring that they are enforced.

Does the network engineer understand the requirements of PCI, SOX, HIPAA, GLBA and the ramifications of non-compliance? Since your CEO and board members can actually go to jail if security is not practiced properly in the organization they are ultimately responsible for – you should ask them. “Who do you want making security decisions and covering your butt? Someone who specializes in this or someone who does not?”

IT and security staff should not be trying to solve this issue – it is too big and more complex than many realize. If you do not have a security officer who understands all of this and works directly with management on these issues, you need to bring in a consultant who gets the big picture and who can talk to both management and IT and develop an actually security program that covers these issues and much more.

Sorry for pontificating and bloviating – this is a struggle that is very common and it personally frustrates me when people who do not understand ‘big picture’ issues make uninformed and dangerous decisions that puts others risk.

PS – Auditors mainly follow Cobit for their auditing framework. Here is exactly what Cobit says about this issue.

1. Cobit

Ensure that all users (internal, external and temporary) and their activity on IT systems (business application, IT environment, system operations, development and maintenance) are uniquely identifiable. Enable user identities via authentication mechanisms. Confirm that user access rights to systems and data are in line with defined and documented business needs and that job requirements are attached to user identities. Ensure that user access rights are requested by user management, approved by system owners and implemented by the security-responsible person. Maintain user identities and access rights in a central repository. Deploy cost-effective technical and procedural measures, and keep them current to establish user identification, implement authentication and enforce access rights.

Define and implement a procedure for identifying new users and recording, approving and maintaining access rights. This needs to be requested by user management, approved by the system owner and implemented by the responsible security person.

2. Industries best standards

Information Security Management Handbook
Edited by Harold F. Tipton and Micki Krause

Security Administrator. The systems security administrator should participate in the selection and implementation of appropriate technical controls and security procedures, understand system vulnerabilities, and be able to respond quickly to system security problems. The security administrator is responsible for the daily administration of user IDs and system controls, and works primarily with the user community

Certain information protection duties must not be performed by the same person or within one area. For example, there should be separation of roles of systems operators, systems administrators, security administrators, and separation of security-relevant functions from others. Admittedly, ideal separation can be costly in time and money, and often possible
only within large staffs. You need to make information security responsibilities dependent upon your business, organization size, and associated risks. You must perform risk assessment to determine what information protection tasks should be centralized and what should be distributed.

3. CSO magazine

CSO is typically tasked with the following responsibilities:

• Act as the company representative with respect to inquiries from customers, partners, and the general public regarding the enterprise's security strategy.
• Act as a company representative when dealing with law enforcement agencies while pursuing the sources of network attacks and information theft by employees.
• Bridge the gap between LOBs and the IT department to balance security needs with the enterprise's strategic business plan, identify risk factors, and determine solutions to both.
• Develop security policies and procedures that provide adequate business application protection without interfering with core business requirements.
• Plan and test responses to security breaches, including the possibility for discussion of the event with customers, partners, or the general public.
• Oversee the selection, testing, deployment, and maintenance of security hardware and software products as well as outsourced arrangements.
• Oversee a staff of employees responsible for enterprise security, ranging from network technicians managing firewall devices to security guards.
• The most important traits for a CSO are excellent interpersonal and written communications skills, solid knowledge of electronic and site security issues, as well as the company's business requirements. More importantly, the individual must possess the leadership abilities to bring IT department and LOB executives to the table, strike a balance between business and security requirements, and persuade all parties involved to pursue a balanced course of action.