Summary
Introduction
This book provides comprehensive methodology, enabling the staff charged with an IT security audit to create a sound framework, allowing them to meet the challenges of compliance in a way that aligns with both business and technical needs. This "roadmap" provides a way of interpreting complex, often confusing, compliance requirements within the larger scope of an organization's overall needs.
Data held on IT systems is valuable and critical to the continued success of any organization. We all rely on information systems to store and process information, so it is essential that we maintain Information Security. The goal of this book is to define an economical and yet secure manner of meeting an organization's compliance needs for IT. To do this we need to understand the terminology that we have based this on and hence the focus of this chapter. We first need to define what security itself is.
The purpose of information security is to preserve:
* Confidentiality Data is only accessed by those with the right to view the data.
* Integrity Data can be relied upon to be accurate and processed correctly.
* Availability Data can be accessed when needed.
Consequently, the securing of information and thus the role of the Security professional requires the following tasks to be completed in a competent manner:
1. The definition and maintenance of security policies/strategies.
2. Implementing and ensuring compliance to Policies and Procedures within the organization:
a. The IT security organization needs a clear statement of mission and strategy. Definition of security roles and processes.
b. Users, administrators, and managers should have clearly defined roles/responsibilities and be aware of them.
c. Users/support staff may require training to be able to assume the responsibilities assigned to them.
3. Effective use of mechanisms and controls to enforce security.
4. Well-defined Technical Guidelines and controls for the systems used within the organization.
5. Assurance (audits and regular risk assessments).
IT security is not about making a perfect system, it is about making a system that is resilient and that can survive the rigors it is exposed to. Compliance comes down to due diligence. If you can show that your system is resilient to attack and that it has a baseline of acceptable controls, you will be compliant with nearly any standard or regulation.
Does Security Belong within IT?
The simple answer is yes. The more developed answer is that information security affects all aspects of an organization, not just IT. Security needs to be the concern of all within an organization from the simple user to senior management.
Management Support
If management does not succeed in the establishment of a sound security infrastructure (including policy, communication, processes, standards, and even culture) within the organization, then there is little likelihood of an organization being able to remain secure. Standards, guidelines, and procedures are developed using the Security Policy. Without these, security cannot be maintained. Without management support there cannot be enforcement, liability, or coordination of incidents. Management support for Information Security controls is fundamental to the continuing security of any organization.
Management can facilitate education and awareness strategies with the organization. Good awareness processes and management support will help in the overall security of an organization because:
1. An organization's personnel cannot be held responsible for their actions unless it can be demonstrated that they were aware of the policy prior to any enforcement attempts.
2. Education helps mitigate corporate and personal liability, avoidance concerning breaches of criminal and civil law, statutory, regulatory, or contractual obligations, and any security requirement.
3. Awareness training raises the effectiveness of security protection and controls; it helps reduce fraud and abuse of the computing infrastructure, and increases the return on investment of the organization's investments in both security as well as in computing infrastructure in general.
Job Roles and Responsibilities
Depending on the size of an organization, responsibility may be divided into the following defined roles. It is important that responsibility is apparent and is supported by management. To achieve this, the accountable persons must actually assume their accountabilities (i.e. they have powers necessary to make corresponding decisions and the experience/knowledge to make the right decisions). Management and Human Resources should ensure that the necessary roles are correctly implemented.
* Board and Executives The Board of Directors and the managing director or CEO (or equivalent) are ultimately responsible for security strategy and must make the necessary resources available to combat business threats. This group is ultimately responsible for disseminating strategy and establishing security-aware customs within the organization. They have the mandate to protect and insure for continuity of the corporation and to protect and insure for profitability of the corporation. Information Security plays a crucial role in both of these aspects of senior management's roles.
* Business process/data/operation owner This person is directly responsible for a particular process or business unit's data and reports directly to top management. He/she analyses the impact of security failures and specifies classification and guidelines/processes to ensure the security of the data for which he/she is responsible. There should not be any influence on auditing.
* Process Owner The process owner is responsible for the process design, not for the performance of the process itself. The process owner is additionally responsible for the metrics linked to the process feedback systems, the documentation of the process, and the education of the process performers in its structure and performance. The process owner is accountable for sustaining the development of the process and for identifying opportunities to improve the process. The process owner is the individual ultimately accountable for improving a process.
* IT Security manager/director This person is responsible for the overall security within the organization. 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. Coordination with partner companies, security organizations, and industry groups is also important.
* System supplier The 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 datacenter or System/Security administrator. This person is responsible for the correct use of security mechanisms.
* 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 These people ensure that Security guidelines are adhered to in projects.
* Line Managers These managers ensure that their personnel are fully aware of security policies and do not provide objectives that 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 the classifying and distribution of this information.
* Auditor The 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.
What Are Audits, Assessments, and Reviews?
The initial thing we need to do is develop a common terminology that we will use. This chapter is designed to introduce the "key terms of art" used within the audit and security profession and to thus allow the IT professional, management, and business to all speak the same language. Terms of art are those terms used in the profession.
Audit
The American Institute of Certified Public Accountants (AICPA) defines two definitive classes of Audit, internal and external. An audit consists of the evaluation of an organization's systems, processes, and controls and is performed against a set standard or documented process. Audits are designed to provide an independent assessment through testing and evaluation of a series of representations about the system or process. An audit may also provide a gap analysis of the operating effectiveness of the internal controls.
External audits are commonly conducted (or at least should be) by independent parties with no rights or capability to alter or update the system they are auditing (AICPA). In many cases, the external auditor is precluded from even advising their client. They are limited to reporting any control gaps and leading the client to a source of accepted principles. Due to these restrictions, an indication of the maturity of a system against an external standard (such as COBIT) is often engaged.
Internal audits involve a feedback process where the auditor may not only audit the system but also potentially provide advice in a limited fashion. They differ from the external audit in allowing the auditor to discuss mitigation strategies with the owner of the system that is being audited.
Neither an internal or external auditor can validly become involved in the implementation or design process. They may assess the level to which a design or implementation meets its desired outcomes, but must be careful not to offer advice on how to design or implement a system. Most crucially, an auditor should never be involved with the audit of a system they have designed and/or implemented.
There is a large variety of audit types. Some examples include SAS 70 (part 1 or 2) audits, audits of ISO 9001, 17799:2/27001 controls, and audits of HIPPA controls. There are many different types of audits and many standards that an audit may be applied to. We go into these in detail later in the book, so do not worry if you are unsure of what they are now. Each of these audit types are documented in the appendixes as well.
An audit must follow a rigorous program. A vulnerability assessment as it is commonly run is more correctly termed a controls assessment. A controls assessment may also be known as a security controls review.
Inspection and Reviews
An audit differs from an inspection in that an audit makes representations about past results and/or performance. An inspection evaluates results at the current point in time. For an audit to be valid, it must be conducted according to accepted principles. In this, the audit team and individual auditors must be certified and qualified for the engagement. Numerous "audits" are provided without certification; these, however, are in consequence qualified reviews.
Penetration Tests and Red Teaming
A Penetration test is an attempt to bypass controls and gain access to a single system. The goal of the Penetration test is to prove that the system may be compromised. A Penetration test does not assess the relative control strength nor the system or processes deployed; rather, it is a "red teaming" (see below for details) styled exercise designed to determine if illicit access can be obtained, but with a restricted scope. The issue is that it is infeasible to prove a negative. As such, there is no scientifically valid manner to determine if all vulnerabilities have been found and this point needs to be remembered when deciding on whether to use a Penetration test process.
(Continues...)
Excerpted from The IT Regulatory and Standards Compliance Handbook by Craig Wright Brian Freedman Dale Liu Copyright © 2008 by Elsevier, Inc.. Excerpted by permission of Syngress. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.