Security policy

Editor's Notes

• #3: Learning Objectives: Upon completion of this material you should be able to: Understand management’s responsibilities and role in the development, maintenance, and enforcement of information security policy, standards, practices, procedures, and guidelines. Understand the differences between the organization’s general information security policy and the needs and objectives of the various issue-specific and system-specific policies the organization will create. Know what an information security blueprint is and what its major components are. Understand how an organization institutionalizes its policies, standards, and practices using education, training and awareness programs. Become familiar with what viable information security architecture is, what it includes, and how it is used.
• #4: Learning Objectives: Upon completion of this material you should be able to: Understand management’s responsibilities and role in the development, maintenance, and enforcement of information security policy, standards, practices, procedures, and guidelines. Understand the differences between the organization’s general information security policy and the needs and objectives of the various issue-specific and system-specific policies the organization will create. Know what an information security blueprint is and what its major components are. Understand how an organization institutionalizes its policies, standards, and practices using education, training and awareness programs. Become familiar with what viable information security architecture is, what it includes, and how it is used.
• #5: Introduction The creation of an information security program begins with an information security blueprint, and before we can discuss the creation and development of a blueprint, it is important to look at management’s responsibility in shaping policy. It is prudent for information security professionals to know the information security polices and how these policies contribute to the overall objectives of the organization. Information Security Policy, Standards and Practices Management from all communities of interest must consider policies as the basis for all information security planning, design, and deployment. In general, policies direct how issues should be addressed and technologies used, not cover the specifics on the proper operation of equipment or software. Quality security programs begin and end with policy. As information security is primarily a management rather than technical problem, policy guides personnel to function in a manner that will add to the security of its information assets. Security policies are the least expensive control to execute, but the most difficult to implement. Shaping policy is difficult because it must: 1)Never conflict with laws. 2)Stand up in court, if challenged. 3)Be properly administered, including thorough dissemination, and documentation from personnel showing they have read the policies.
• #6: A policy is A plan or course of action, as of a government, political party, or business, intended to influence and determine decisions, actions, and other matters Policies are organizational laws Policies must contain information on what is right, and what is not; what the penalties are for violating policy, and what the appeal process is Standards, on the other hand, are more detailed statements of what must be done to comply with policy Practices, procedures and guidelines effectively explain how to comply with policy For a policy to be effective it must be properly disseminated, read, understood and agreed to by all members of the organization.
• #7: Types of Policy Management defines three types of security policy: 1)General or security program policy 2)Issue-specific security policies 3)Systems-specific security policies
• #9: Security Program Policy A security program policy (SPP) is also known as a general security policy, IT security policy, or information security policy. This policy sets the strategic direction, scope, and tone for all security efforts within the organization. The SPP is an executive-level document, usually drafted by or with, the CIO of the organization and is usually 2 to 10 pages long. When the SPP has been developed, the CISO begins forming the security team and initiates the SecSDLC process.
• #10: Issue-Specific Security Policy (ISSP) As the organization executes various technologies and processes to support routine operations, certain guidelines are needed to instruct employees to use these technologies and processes properly. In general, the ISSP 1) addresses specific areas of technology 2) requires frequent updates, and 3) contains an issue statement on the organization’s position on an issue. There are a number of approaches toward creating and managing ISSPs within an organization. Three of the most common are: Create a number of independent ISSP documents, each tailored to a specific issue Create a single comprehensive ISSP document attempting to cover all issues Create a modular ISSP document that unifies policy creation and administration, while maintaining each specific issue’s requirements
• #11: ISSP Structure Statement of Policy The policy should begin with a clear statement of purpose. The introductory section should outline the scope and applicability of the policy. What does this policy address? Who is responsible and accountable for policy implementation? What technologies and issues does the policy document address? Authorized Access and Usage of Equipment This section of the policy statement addresses who can use the technology governed by the policy, and what it can be used for. This section defines “fair and responsible use” of equipment and other organizational assets and should also address key legal issues, such as protection of personal information and privacy. Prohibited Usage of Equipment While the policy section described above detailed what the issue or technology can be used for, this section outlines what it cannot be used for. Unless a particular use is clearly prohibited, the organization cannot penalize its employees. Systems Management There may be some overlap between an ISSP and a systems-specific policy, but this section of the policy statement focuses on the users relationship to systems management. It is important to identify all responsibilities delegated to both users or the systems administrators, to avoid confusion. Violations of Policy Once guidelines on equipment use have been outlined and responsibilities have been assigned, the individuals to whom the policy applies must understand the penalties and repercussions of violating the policy. Violations of policy should carry appropriate penalties. This section should also provide instructions on how individuals in the organization can report observed or suspected violations, either openly or anonymously. Policy Review and Modification Since any document is only as good as its frequency of review, each policy should contain procedures and a timetable for periodic review. Limitations of Liability The final section is a general statement of liability or set of disclaimers. The policy should state that if employees violate a company policy or any law using company technologies, the company will not protect them and the company is not liable for their actions.
• #13: Systems-Specific Policy (SysSP) While issue-specific policies are formalized as written documents, distributed to users, and agreed to in writing, SysSPs are frequently codified as standards and procedures used when configuring or maintaining systems. Systems-specific policies fall into two groups: 1)Access control lists (ACLs) consists of the access control lists, matrices, and capability tables governing the rights and privileges of a particular user to a particular system. 2)Configuration Rules comprise the specific configuration codes entered into security systems to guide the execution of the system
• #14: ACL Policies Both Microsoft Windows NT/2000 and Novell Netware 5.x/6.x families of systems translate ACLs into sets of configurations that administrators use to control access to their respective systems. ACLs allow configuration to restrict access from anyone and anywhere. ACLs regulate: Who can use the system. What authorized users can access. When authorized users can access the system. Where authorized users can access the system from. How authorized users can access the system.
• #17: Rule Policies Rule policies are more specific to the operation of a system than ACLs, and may or may not deal with users directly. Many security systems require specific configuration scripts telling the systems what actions to perform on each set of information they process.
• #19: Policy Management Policies are living documents that must be managed and nurtured, and are constantly changing and growing. These documents must be properly disseminated and managed. Special considerations should be made for organizations undergoing mergers, takeovers and partnerships. In order to remain viable, these policies must have: an individual responsible for reviews, a schedule of reviews, a method for making recommendations for reviews, and an indication of policy and revision date.
• #20: Information Classification The classification of information is an important aspect of policy. The same protection scheme created to prevent production data from accidental release to the wrong party should be applied to policies in order to keep them freely available, but only within the organization. In today’s open office environments, it may be beneficial to implement a clean desk policy. A clean desk policy stipulates that at the end of the business day, all classified information must be properly stored and secured.
• #22: Systems Design At this point in the Security SDLC, the analysis phase is complete and the design phase begins. At the end of the analysis phase, the security team has: created an assessment of the threats to the information and systems and has prioritized those threats developed a prioritized inventory of the organization’s information assets Developed an evaluation of the current asset-threat-vulnerability environment completed risk assessments with either a quantitative or qualitative analysis of the protection of each asset, or has prepared a benchmark comparison of security standards from similarly structured organizations. completed a set of feasibility studies identifying whether or not controls should proceed as planned. Designing a working plan for securing the organization’s information assets begins by creating or validating the security blueprint for the implementation of needed security controls to protect the information assets. The next step is to use the blueprint to plan the tasks to be accomplished and the order in which to proceed. Setting priorities can follow the recommendations of published sources, or from published standards provided by government agencies, or private consultants.
• #24: Information Security Blueprints One approach to selecting a methodology is to adapt or adopt a published model or framework for information security. A framework is the basic skeletal structure within which additional detailed planning of the blueprint can be placed as it is developed of refined. Experience teaches us that what works well for one organization may not precisely fit another.
• #25: ISO 17799/BS 7799 One of the most widely referenced and often discussed security models is the Information Technology – Code of Practice for Information Security Management, which was originally published as the British Standard BS 7799. This Code of Practice was adopted as an international standard by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) as ISO/IEC 17799 in 2000 as a framework for information security.
• #27: ISO 17799/BS 7799 Several countries including the United States, Germany, and Japan have not adopted 17799. They claim that there are several fundamental problems: 1)The global information security community has not defined any justification for a code of practice as identified in the ISO/IEC 17799. 2)17799 lacks “the necessary measurement precision of a technical standard” . 3)There is no reason to believe that 17799 is more useful than any other approach currently available. 4)17799 is not as complete as other frameworks available. 5)17799 is perceived to have been hurriedly prepared given the tremendous impact its adoption could have on industry information security controls.
• #28: ISO/IEC 17799 1.Organizational Security Policy is needed to provide management direction and support for information security. 2.Organizational Security Infrastructure objectives: Manage information security within the company Maintain the security of organizational information processing facilities and information assets accessed by third parties Maintain the security of information when the responsibility for information processing has been outsourced to another organization 3.Asset Classification and Control is needed to maintain appropriate protection of corporate assets and to ensure that information assets receive an appropriate level of protection. 4.Personnel Security objectives: Reduce risks of human error, theft, fraud or misuse of facilities Ensure that users are aware of information security threats and concerns, and are equipped to support the corporate security policy in the course of their normal work Minimize the damage from security incidents and malfunctions and learn from such incidents 5.Physical and Environmental Security objectives: Prevent unauthorized access, damage and interference to business premises and information Prevent loss, damage or compromise of assets and interruption to business activities Prevent compromise or theft of information and information processing facilities 6. Communications and Operations Management objectives: Ensure the correct and secure operation of information processing facilities Minimize the risk of systems failures Protect the integrity of software and information Maintain the integrity and availability of information processing and communication Ensure the safeguarding of information in networks and the protection of the supporting infrastructure Prevent damage to assets and interruptions to business activities Prevent loss, modification or misuse of information exchanged between organizations 7.System Access Control objectives in this area include: Control access to information Prevent unauthorized access to information systems Ensure the protection of networked services Prevent unauthorized computer access Detect unauthorized activities Ensure information security when using mobile computing and telecommunication networks 8.System Development and Maintenance objectives: Ensure security is built into operational systems Prevent loss, modification or misuse of user data in application systems Protect the confidentiality, authenticity and integrity of information Ensure IT projects and support activities are conducted in a secure manner Maintain the security of application system software and data 9.Business Continuity Planning to counteract interruptions to business activities and to critical business processes from the effects of major failures or disasters. 10. Compliance objectives: Avoid breaches of any criminal or civil law, statutory, regulatory or contractual obligations and of any security requirements Ensure compliance of systems with organizational security policies and standards Maximize the effectiveness of and minimize interference to/from the system audit process
• #29: NIST Security Models Another approach available is described in the many documents available from the Computer Security Resource Center of the National Institute for Standards and Technology (csrc.nist.gov). These are among the references cited by the government of the U.S. when deciding not to select the ISO/IEC 17799 standards. NIST SP 800-12 - The Computer Security Handbook is an excellent reference and guide for the security manager or administrator in the routine management of information security. NIST SP 800-14 - Generally Accepted Principles and Practices for Securing IT Systems provides best practices and security principles that can direct the development of a security blueprint. NIST SP 800-18 - The Guide for Developing Security Plans for IT Systems is considered the foundation for a comprehensive security blueprint and framework. It provides detailed methods for assessing, designing, and implementing controls and plans for various sized applications.
• #30: NIST SP 800-14 Generally Accepted Principles and Practices Security Supports the Mission of the Organization Security is an Integral Element of Sound Mgmt Security Should Be Cost-Effective Systems Owners Have Security Responsibilities Outside Their Own Organizations Security Responsibilities and Accountability Should Be Made Explicit Security Requires a Comprehensive and Integrated Approach Security Should Be Periodically Reassessed Security is Constrained by Societal Factors 1. Establish a sound security policy as the “foundation” for design. 2. Treat security as an integral part of the overall system design. 3. Clearly delineate the physical and logical security boundaries governed by associated security policies. 4. Reduce risk to an acceptable level. 5. Assume that external systems are insecure. 6. Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of operational effectiveness. 7. Implement layered security (Ensure no single point of vulnerability). 8. Implement tailored system security measures to meet organizational security goals. 9. Strive for simplicity. 10. Design and operate an IT system to limit vulnerability and to be resilient in response. 11. Minimize the system elements to be trusted. 12. Implement security through a combination of measures distributed physically and logically. 13. Provide assurance that the system is, and continues to be, resilient in the face of expected threats. 14. Limit or contain vulnerabilities. 15. Formulate security measures to address multiple overlapping information domains. 16. Isolate public access systems from mission critical resources (e.g., data, processes, etc.). 17. Use boundary mechanisms to separate computing systems and network infrastructures. 18. Where possible, base security on open standards for portability and interoperability. 19. Use common language in developing security requirements. 20. Design and implement audit mechanisms to detect unauthorized use and to support incident investigations. 21. Design security to allow for regular adoption of new technology, including a secure and logical technology upgrade process. 22. Authenticate users and processes to ensure appropriate access control decisions both within and across domains. 23. Use unique identities to ensure accountability. 24. Implement least privilege. 25. Do not implement unnecessary security mechanisms. 26. Protect information while being processed, in transit, and in storage. 27. Strive for operational ease of use. 28. Develop and exercise contingency or disaster recovery procedures to ensure appropriate availability. 29. Consider custom products to achieve adequate security. 30. Ensure proper security in the shutdown or disposal of a system. 31. Protect against all likely classes of “attacks.” 32. Identify and prevent common errors and vulnerabilities. 33. Ensure that developers are trained in how to develop secure software.
• #38: IETF Security Architecture While no specific architecture is promoted through the Internet Engineering Task Force, the Security Area Working Group acts as an advisory board for the protocols and areas developed and promoted through the Internet Society. RFC 2196: Site Security Handbook provides an overview of five basic areas of security with detailed discussions on development and implementation. There are chapters on such important topics as security policies, security technical architecture, security services, and security incident handling.
• #39: Visa International® Security Model Visa International, the credit card processing vendor, promotes strong security measures in its business associates, and has established guidelines for the security of its information systems. Visa has developed two important documents that improve and regulate its information systems: “Security Assessment Process” and “Agreed Upon Procedures.” Using the two documents, a security team can develop a sound strategy for the design of good security architecture. The only down side to this approach is the very specific focus on systems that can or do integrate with VISA’s systems with the explicit purpose of carrying the aforementioned cardholder information.
• #40: Baselining and Best Business Practices Baselining and best practices are solid methods for collecting security practices, but can have the drawback of providing less detail for the design and implementation of all the practices needed by an organization, than would a complete methodology. However, it is possible to gain information by baselining and using best practices, to piece together the desired outcome of the security process, and thus work backwards to an effective design. The Federal Agency Security Practices Site (fasp.csrc.nist.gov) is designed to provide best practices for public agencies, but can be adapted easily to private institutions. The documents found in this site include specific examples of key policies and planning documents, implementation strategies for key technologies, and outlines of hiring documents for key security personnel.
• #41: Professional Membership It may be worth the information security professional’s time and money to join professional societies with information on best practices for its members. Many organizations have seminars and classes on best practices for implementing security. Finding information on security design is the easy part. Sorting through the collected mass of information, documents, and publications can take a substantial investment in time and human resources.
• #42: NIST SP 800-26 Security Self-Assessment Guide for IT Systems Management Controls 1. Risk Management 2. Review of Security Controls 3. Life Cycle Maintenance 4. Authorization of Processing (Certification and Accreditation) 5. System Security Plan Operational Controls 6. Personnel Security 7. Physical Security 8. Production, Input/Output Controls 9. Contingency Planning 10. Hardware and Systems Software 11. Data Integrity 12. Documentation 13. Security Awareness, Training, and Education 14. Incident Response Capability Technical Controls 15. Identification and Authentication 16. Logical Access Controls 17. Audit Trails
• #43: Figure 6-16, showing the sphere of security, is the foundation of the security framework. Generally speaking, the sphere of security represents the fact that information is under attack from a variety of sources. The sphere of use, at the left of the figure, illustrates the ways in which people can directly access information: for example, people read hard copies of documents; they also access information through systems, such as the electronic storage of information. Information, as the most important asset to security, is illustrated at the core of the sphere. Information is always at risk from attacks through the people and computer systems that have direct access to the information. Networks and the Internet represent indirect threats, as exemplified by the fact that a person attempting to access information from the Internet must first go through the local networks and then access systems that contain the information. The sphere of protection, at the right of the figure, illustrates that between each layer of the sphere of use there must exist a layer of protection to prevent access to the inner layer from the outer layer. Each shaded band is a layer of protection and control. For example, the layer labeled “policy education and training” is located between people and the information. Controls are also implemented between systems and the information, between networks and the computer systems, and between the Internet and internal networks. This reinforces the concept of defense in depth. As illustrated in the sphere of protection portion of Figure 6-16, a variety of controls can be used to protect the information. The list in the figure is not intended to be comprehensive but illustrates individual safeguards that protect the various systems that are located closer to the center of the sphere. However, as people can directly access each ring as well as the information at the core of the model, people require unique approaches to security. In fact, the resource of people must become a layer of security, a human firewall that protects the information from unauthorized access and use. The members of the organization must become a safeguard, which is effectively trained, implemented, and maintained, or else they, too, become a threat to the information.
• #44: Sphere of Use Generally speaking, the concept of the sphere is to represent the 360 degrees of security necessary to protect information at all times. The first component is the “sphere of use.” Information, at the core of the sphere, is available for direct access by members of the organization and other computer-based systems. To gain access to the computer systems, one must either directly access the computer systems or go through a network connection. To gain access to the network, one must either directly access the network or go through an Internet connection.
• #45: Sphere of Protection The “sphere of protection” overlays each of the levels of the “sphere of use” with a layer of security, protecting that layer from direct use or indirect use through the next layer. The resource of people must become a layer of security, a human firewall that protects the information from unauthorized access and use. Information security is therefore designed and implemented in three layers: Policies, people (education, training and awareness programs) and technology.
• #46: Controls Management Controls cover security processes that are designed by the strategic planners and performed by security administration of the organization. Management controls address the design and implementation of the security planning process and security program management. Operational Controls deal with the operational functionality of security in the organization. They cover management functions and lower level planning, such as disaster recovery and incident response planning. Operational controls also address personnel security, physical security and the protection of production inputs and outputs. Technical Controls address those tactical and technical issues related to designing and implementing security in the organization. Technical controls cover logical access controls, like identification, authentication, authorization, and accountability.
• #47: The Principles of Information Security Framework Management Controls Program Management System Security Plan Life Cycle Maintenance Risk Management Review of Security Controls Legal Compliance Operational Controls Contingency Planning Security ETA Personnel Security Physical Security Production Inputs and Outputs Hardware & Software Systems Maintenance Data Integrity Technical Controls Logical Access Controls Identification, Authentication, Authorization and Accountability Audit Trails Asset Classification and Control Cryptography
• #48: Security Education, Training, And Awareness Program As soon as the policies have been drafted outlining the general security policy, policies to implement security education, training and awareness (SETA) programs in the organization should follow. The SETA program is a control measure designed to reduce the incidences of accidental security breaches by employees. SETA programs are designed to supplement the general education and training programs in place to educate staff on information security. Security education and training is designed to build on the general knowledge the employees must possess to do their jobs, familiarizing them with the way to do their jobs, securely.
• #49: SETA Elements The SETA program consists of three elements: security education, security training, and security awareness. The organization may not be capable or willing to undertake all three of these elements, but may outsource them. The purpose of SETA is to enhance security by: Improving awareness of the need to protect system resources Developing skills and knowledge so computer users can perform their jobs more securely Building in-depth knowledge, as needed, to design, implement, or operate security programs for organizations and systems.
• #52: Security Education Everyone in an organization needs to be trained and aware of information security, but not every member of the organization needs a formal degree or certificate in information security. When formal education for appropriate individuals in security is needed, with the support of management, an employee can identify curriculum available from local institutions of higher learning or continuing education. A number of universities have formal coursework in information security. (See for example http://infosec.kennesaw.edu).
• #53: Security Training Security training involves providing members of the organization with detailed information and hands-on instruction designed to prepare them to perform their duties securely. Management of information security can develop customized in-house training or outsource the training program.
• #54: Security Awareness One of the least frequently implemented, but the most beneficial programs is the security awareness program. A security awareness program is designed to keep information security at the forefront of the users’ minds at they work day-to-day. These programs don’t have to be complicated or expensive. The goal is to keep the idea of information security in the user’s minds and to stimulate them to care about security. If the program is not actively implemented, employees begin to ‘tune out’, and the risk of employee accidents and failures increases.
• #56: Comments On The Design Of Security Architecture Defense in Depth – One of the foundations of security architectures is the requirement to implement security in layers. Defense in depth requires that the organization establish sufficient security controls and safeguards, so that an intruder faces multiple layers of controls. Security Perimeter – The point at which an organization’s security protection ends, and the outside world begins, is referred to as the security perimeter. Unfortunately the perimeter does not apply to internal attacks from employee threats, or on-site physical threats.
• #59: Key Technology Components A few other key technology components that are important to understand during the design phase of a security architecture are the firewall, proxy server, intrusion detection systems, and the DMZ. A firewall is a device that selectively discriminates against information flowing into or out of the organization. A firewall is usually a computing device, or specially configured computer that allows or prevents information from entering or exiting the defined area based on a set of predefined rules. The DMZ (demilitarized zone) is a no-man’s land, between the inside and outside networks, where some organizations place Web servers. These servers provide access to organizational Web pages, without allowing Web requests to enter the interior networks. An alternative approach to this strategy is to use a proxy server or firewall. A proxy server performs actions on behalf of another system. When an outside client requests a particular Web page, the proxy server receives the request then asks for the same information from the true Web server. In an effort to detect unauthorized activity within the inner network, or on individual machines, an organization may wish to implement Intrusion Detection Systems or IDS. Host-based IDS are usually installed on the machine the organization wishes to protect and to safeguard that particular system from unauthorized use by monitoring the status of various files stored on that system. Network-based IDS look at patterns of network traffic and attempt to detect unusual activity based on previous baselines.