Security organisation

Organizational structure

Actual Organizational structure is not discussed here, since every company is different. Rather, roles are described. These roles can be attributed to different persons in an organization depending on it's structure, size, culture etc. 
  
Roles and Responsibility

Depending on company size, responsibility may be attributed to the following roles. What is important is that responsibility is clear and that the responsible persons can actually assume their responsibilities (i.e. the have powers necessary to take corresponding decisions an the experience/knowledge to take the right decisions).

Executives: The managing director, CEO or equivalent is ultimately responsible for security strategy and must make the necessary resources available to combat business threats. This person is also responsible for disseminating strategy and establishing a security-aware culture.

IT Security manager: is responsible for Enterprise security. The IT security manager(s) defines IT security guidelines together with the process owner. He/she is also responsible for security awareness and advising management correctly on security issues. He/she may also carry out risk analyses. It is important that this person be up-to-date on the latest security problems/risks/solutions. Co-ordination with partner companies, security organisations is also important.

Business process / data / operation owner: is directly responsible for a particular process or business unit's data and reports directly to top management. He analyses the impact of security failures and specifies classification and guidelines/processes to ensure the security of the data for which he is responsible. He should not have any influence on auditing.
 
System supplier: Installs and maintains systems. A service level agreement should exist defining the customer/supplier roles and responsibilities. The supplier may be, for example, an external contracting company or the internal datacentre or System/Security administrator. He is responsible for the correct use of security mechanisms. Often this person is root (UNIX) or dba (databases).

System designer: The persons who develop a system have a key role in ensuring that a system can be used securely. New development projects must consider security requirements at an early stage.

Project Leaders: ensure that Security guidelines are adhered to in projects.

Line Managers: ensures that his personnel are fully aware of security policies and does not provide objectives which conflict with policy. He/she enforces policy and checks actual progress.

Users: Users, or "information processors/operators" are responsible for their actions. They are aware of company security policy, understand what the consequences of their actions are and act accordingly. They have effective mechanisms at their disposal so that they can operate with the desired level of security. Should users receive confidential information that is not classified, they are responsible for classifying and distribution of this information.

Auditor: is an independent person, within or outside the company, who checks the status of IT security, much in the same way as a Financial Auditor verifies the validity of accounting records. It is important that the Auditor be independent, not being involved in security administration. Often external consultants fulfill this role, since they can offer a more objective view of policies, processes, organizations and mechanisms.
  

Processes

The security policy needs processes and people (organization) to ensure it's implementation and accordance with business needs. Typical security processes are:

• Security Hotline / Helpdesk (user management)
• Change management
• System monitoring & intruder detection
• Data backup & recovery
• System audits
• Crisis management/Firewall

  1. Security Hotline/ Helpdesk

• User account management is often available over a so-called hotline or helpdesk.
• The help-desk is where users call when they have problems. If the helpdesk cannot resolve a problem, it is responsible for escalation (and tracking) of the problem to vendors or system administrators, for example.
• Users should have access to a service hotline to unlock passwords quickly (if they forget them), otherwise users may write the passwords down.
• How can password be exchanged over the phone? How can you be sure that the correct user is asking for an allowed modification? Some kind of "authentication" is required. (Perhaps by using internal phone systems where the calling number is visible?, or by calling the user back at his desk?)

2. Change Management

• Who installs or upgrades HW and SW?
• New SW should be tested for a few weeks before being installed on production systems.
• Changes should be carefully prepared and carried out such that production is not disturbed and such that if the changes have a negative effect, they can be removed. During hardware changes ensure that anti-static wrist straps are worn, that the correct tools are available and that the power is connected or removed according to the manufacturer's instructions.
• Follow the axioms KISS (Keep it simple, stupid) and "if it isn't broken, don't fix it". Only install updates if they are necessary.

3. Systems monitoring

Who monitors what systems, where, with what utilities? Monitoring is often more effective if decentralized in very large organizations.

4. Data Backup & Restore

Processes & responsibility need to be defined to ensure reliable backups and restores when needed. The restore policy should be regularly tested.

5. System audits

• Servers should be audited regularly (e.g. once per year).
• A audit checklist should be made for each security level/OS, for simplicity.
• The auditor should be independent of the administration and be objective.
• The audit should check: Guidelines, Policies, Users, Management, IT Security managers, Administrators, IT Resources.

6. Crisis Management / "Firewall" / Emergency Response Team / Disaster Planning

Even with a solid security policy, educated users and solid system administration, an emergency response team is useful. Plan for a disaster!

• Who is on "Firewall", how should they react to a serious security breach?
• If internal personnel are not expert enough, a "emergency standby" contract could be outsourced to a specialized company.
• Decide in advance who will be in charge in the event of a security incident. Determine the chain of command (define processes & responsibility).
• Keep important names, telephone numbers, email addresses off-line. Do not assume that your on-line address book will be available in an emergency.

Security Marketing

Communications Manager: responsible for spreading security awareness in the company. 

Security Information Center

Having the right information at the right time is important.

• It is advisable to have the current books on relevant security topics available, access to Internet security Newsgroups, mailing lists, WWW servers and ftp servers.
• All corporate documents on security and the standards on which they are based should be available.
• Copies of rules, policies, documentation and addresses should be kept off-line (or even better on paper).

The following services could be offered to internal departments:

• A Security Library (as detailed above).
• Risk analysis.
• Education: Courses on IT security for users, administrators, line managers etc.
• Technical expertise (for each important OS / application / system) who follows security developments. Each specialist must be aware of all new security problems & fixes.
• Guidance in the purchasing / development of new systems.
• Testing of new systems.
• One time audits of systems & processes: do systems conform to policy, what weaknesses do they have?
• Statistical analysis: regular reporting of system usage, performance, user behaviour, technological trends, external connection usage.