Information security policies

From Wikipedia, the free encyclopedia

Information security policies are a special type of documented business rule for protecting information and the systems which store and process the information. Information security policies are usually documented in one or more information security policy documents. Within an organization, these written policy documents provide a high-level description of the various controls the organization will use to protect information.

Written information security policy documents are also a formal declaration of management's intent to protect information, and are required for compliance with various security and privacy regulations. Organizations that require audits of their internal systems for compliance with various regulations will often use information security policies as the reference for the audit.

Developing Information Security Policies

Proper development of information security policies requires careful planning. While information security policies are usually developed by one group, such as the information security department, policy development requires the input of all major business units within the organization. The policy development process has five major steps:

1. Assemble the policy development team - The team can include both primary and secondary members. Primary members will be the persons who write the policies, and should include at least one information security specialist and ideally a technical writer to help produce documents that are easy to read and understand. Secondary team members will help build requirements, review and approve documents. Ideal secondary team members include representatives from legal, human resources (HR), information technology (IT) and various business units.
2. Gather Requirements - Decide which topics will be covered within your policy documents. Use the results of your organizational risk assessment to determine which parts of the organization are at greatest risk.
3. Write Draft Policy Documents - Create draft policy documents for each major policy topic you will address. Be sure to use consistent style and formatting between documents.
4. Review and approve draft policy documents - Send each document for review to members of the review team. Ideally, team members should commit to reviewing each document within a definted time period.
5. Formally publish written documents - Once each document has been formally approved, they can be published to the organization. Official publication of these documents should be sanctioned with the support of a high-level executive within the organization, preferable the CEO or CIO.

Resources

The following resources will help in development and deployment of information security policies:
The SANS Security Policy Project provides a set of sample information security policy documents.
Information Security Policies the complete RUsecure security policy definition document.
Information Security Roles and Responsibilities Made Easy by Charles Cresson Wood provides advice for building a proper information security organization, including sample security-related job descriptions.

Security policy

From Wikipedia, the free encyclopedia

A security policy is a definition of what it means to be secure for a system, organization or other entity. For an organization, it addresses the constraints on behavior of its members as well as constraints imposed on adversaries by mechanisms such as doors, locks, keys and walls. For systems, the security policy addresses constraints on functions and flow among them, constraints on access by external systems and adversaries including programs and access to data by people.

Because the security policy is a high level definition of secure behavior, it is meaningless to claim an entity is "secure" without knowing what "secure" means. It is also foolish to make any significant effort to address security without tracing the effort to a security policy.

Significance

If it is important to be secure, then it is important to be sure all of the security policy is enforced by mechanisms that are strong enough. There are organized methodologies and risk assessment strategies to assure completeness of security policies and assure that they are completely enforced. In complex systems, such as information systems, policies can be decomposed into sub-policies to facilitate the allocation of security mechanisms to enforce sub-policies. However, this practice has pitfalls. It is too easy to simply go directly to the sub-policies, which are essentially the rules of operation and dispense with the top level policy. That gives the false sense that the rules of operation address some overall definition of security when they do not. Because it is so difficult to think clearly with completeness about security, rules of operation stated as "sub-policies" with no "super-policy" usually turn out to be rambling ad-hoc rules that fail to enforce anything with completeness. Consequently, a top level security policy is essential to any serious security scheme and sub-policies and rules of operation are meaningless

ISO/IEC 27002

From Wikipedia, the free encyclopedia

ISO/IEC 27002 is an information security standard published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) as ISO/IEC 17799:2005 and subsequently renumbered ISO/IEC 27002:2005 in July 2007, bringing it into line with the other ISO/IEC 27000-series standards. It is entitled Information technology - Security techniques - Code of practice for information security management. The current standard is a revision of the version first published by ISO/IEC in 2000, which was a word-for-word copy of the British Standard (BS) 7799-1:1999.

ISO/IEC 27002 provides best practice recommendations on information security management for use by those who are responsible for initiating, implementing or maintaining Information Security Management Systems (ISMS). Information security is defined within the standard in the context of the C-I-A triad:

the preservation of confidentiality (ensuring that information is accessible only to those authorised to have access), integrity (safeguarding the accuracy and completeness of information and processing methods) and availability (ensuring that authorised users have access to information and associated assets when required).

After the introductory sections, the standard contains the following twelve main sections:

* 1: Risk assessment and treatment - analysis of the organization's information security risks
* 2: Security policy - management direction
* 3: Organization of information security - governance of information security
* 4: Asset management - inventory and classification of information assets
* 5: Human resources security - security aspects for employees joining, moving and leaving an organization
* 6: Physical and environmental security - protection of the computer facilities
* 7: Communications and operations management - management of technical security controls in systems and networks
* 8: Access control - restriction of access rights to networks, systems, applications, functions and data
* 9: Information systems acquisition, development and maintenance - building security into applications
* 10: Information security incident management - anticipating and responding appropriately to information security breaches
* 11: Business continuity management - protecting, maintaining and recovering business-critical processes and systems
* 12: Compliance - ensuring conformance with information security policies, standards, laws and regulations

Within each section, information security controls and their objectives are specified and outlined. The information security controls are generally regarded as best practice means of achieving those objectives. For each of the controls, implementation guidance is provided. Specific controls are not mandated since:

1. Each organization is expected to undertake a structured information security risk assessment process to determine its specific requirements before selecting controls that are appropriate to its particular circumstances. (The introduction section outlines a risk assessment process although there are more specific standards covering this area such as ISO Technical Report TR 13335 GMITS Part 3 - Guidelines for the management of IT security - Security Techniques, and BS 7799 Part 3.)
2. It is practically impossible to list all conceivable controls in a general purpose standard. (Industry-specific implementation guidance for ISO/IEC 27001 and 27002 are anticipated to give advice tailored to organizations in the telecomms, financial services, healthcare, lotteries and other industries).

ISO/IEC 27002 has directly equivalent national standards in countries such as Australia and New Zealand (AS/NZS ISO/IEC 17799:2006), the Netherlands (NEN-ISO/IEC 17799:2002 nl, 2005 version in translation), Denmark (DS484:2005), Sweden (SS 627799), Japan (JIS Q 27002), UNE 71501 (Spain), the United Kingdom (BS ISO/IEC 17799:2005) and Uruguay (UNIT/ISO 17799:2005). Translation and local publication often results in several months' delay after the main ISO/IEC standard is revised and released but the national standard bodies go to great lengths to ensure that the translated content accurately and completely reflects ISO/IEC 27002.