Information Security For Protecting Business


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Before we begin our discussion about policies, lets talk a little about trust. Trust is a central theme in many policies. Some policies may not be written because there is trust that people will do the right thing. Then on the other hand, some policies are needed because we know people don.t always do the right thing. Ideally you want to trust all resources, but that is unrealistic. Buggy hardware and software are commonplace. Try to implement controls and procedures to minimize the impact when a failure does occur. Trust of employees and users develops over time. Different categories of employees should be trusted at different levels. Ensure level of access is commensurate with level of trust.
  • When looking at trust, you have three basic models . those listed above. It is not very common to find organizations that follow the model of trusting everyone all of the time. In today.s world it is just not possible. On the same token the model of trusting no one at no time is also not that common. This model is mostly found in high level security government organizations. The most common model is to trust some of the people some of the time and to build trust over time. Also keep in mind that it may be appropriate to apply different trust models to different parts of the organization.
  • My experience in the field has consistently shown that security policies tend to elevate the level of tension in any given situation. It basically boils down to the fact that people don.t like rules and don.t like to be restricted in their activities. One reason for the tension level is that everyone tends to view security needs differently: .Users are concerned about being able to get their work done without a lot of controls. .System support personnel are concerned about the ease of managing systems under tight control. .Management is concerned about costs versus protection. Getting all sides to agree about the elements of a policy is nearly impossible. It is always best to try to reach a .win-win. compromise.
  • Basically, everyone should be concerned security policies because everyone is affected by them to some extent. The system users are typically affected the most as they see the policies as a set of rules to regulate their behavior and make it more difficult for them to accomplish their job. The people who have to support the infrastructure are concerned since they are the ones who have to implement and comply by many of the policies. For example, a policy that requires all Solaris hosts to be installed according to a baseline security standard would require more work on the part of the system administrators. Not only for the initial install, but also for the upkeep of the system.
  • Ideally, you should have a formal policy design process that is consistently followed for all security policies. The process would specify who develops the initial draft of the policy, which groups are required to review each policy, the required approval process and finally the implementation process. The SAGE booklet .A Guide to Developing Computing Policy Documents., recommends: a senior level administrator a member of management who can enforce the policy a member of the legal staff a representative from the user community someone with good writing skills The size of the policy design group will depend on the size and scope of the policy. Small scale policies may only require one or two people while large scale policies may require a team of 5-10.
  • If at all possible, notify people in advance that a new policy is being developed and explain why the policy is needed. Prior to deploying a new policy, allow people one-two weeks to review and comment. People given responsibility in a policy should also have the authority to carry out their responsibilities.
  • This page discusses some basic rules for policies. While many of these may seem obvious, it is necessary to point them out. When planning policies, some organizations will go overboard with policies and come up with something that will be impossible to implement and comply with. The bottom line for policies is they must take into consideration the balance of protection with the level of productivity hit. You also want policies to be concise and easy to read and understand. Our goal at Cisco is to keep policies to 2 pages or less, if at all possible. We do have a few policies which are 4 or 5 pages. One thing to keep in mind when developing a policy is how it will effect legacy systems and other infrastructure that is already in place. Once the policies are fully approved, they should be made available to all users who are affected. Finally, all policies should be updated annually to reflect changes in organization or culture.
  • One of the major goal of a policy is to implement control. Deciding on the level of control for a specific policy is not always clear-cut. The security needs and the culture of the organization will play a major role when deciding what level of control is appropriate. If you make policies too restrictive or too hard to implement and comply with, they will either be ignored (not implemented) or people will find a way to circumvent the controls in the policies.
  • There are potentially dozens of policy topics that may be appropriate for most mid to large size organizations. Some of Cisco.s major policies: Acceptable Encryption Application Service Providers Acceptable User Acquisition Assessment Audit Risk Assessment Information Sensitivity Password Laptop Security DMZ Equipment Extranet Host Security Lab Security Anti-Virus Router/Switch Wireless Communications Remote Access VPN
  • Example policies and procedures can be found on the SANS web site at: The Acceptable Use policy is probably one of the most important policies a site can have. For educational and government organizations, it is basically a .must have.. Without such a written policy, management and support staff have nothing they can reference when attempting to punish an employee/guest who has violated the acceptable, safe computing practices.
  • Example Text: 1. It is the responsibility of <Company Name> employees, contractors, vendors and agents with remote access privileges to <Company Name>'s corporate network to ensure that their remote access connection is given the same consideration as the user's on-site connection to <Company Name>. 2. General access to the Internet for recreational use by immediate household members through the <Company Name> Network on personal computers is permitted for employees that have flat-rate services. The <Company Name> employee is responsible to ensure the family member does not violate any <Company Name> policies, does not perform illegal activities, and does not use the access for outside business interests. The <Company Name> employee bears responsibility for the consequences should the access be misused. 3. Please review the following policies for details of protecting information when accessing the corporate network via remote access methods, and acceptable use of <Company Name>'s network: a. Acceptable Encryption Policy b. Virtual Private Network (VPN) Policy c. Wireless Communications Policy d. Acceptable Use Policy 4. For additional information regarding <Company Name>'s remote access connection options, including how to order or disconnect service, cost comparisons, troubleshooting, etc., go to the Remote Access Services website.
  • Even though it may seem like common sense to protect company private information, many employees don.t take the time to consider the sensitivity level of much of the information they see. If possible, attach a level rating to information sent out via email and interoffice mail. Employees who work exclusively on a laptop need to be more cautious of protecting information stored on that system. Especially when traveling, where the likelihood that strangers will gain access to the laptop or steel the laptop is dramatically higher.
  • Example Text: All <Company Name> PC-based lab computers must have <Company Name>'s standard, supported anti-virus software installed and scheduled to run at regular intervals. In addition, the anti-virus software and the virus pattern files must be kept up-to-date. Virus-infected computers must be removed from the network until they are verified as virus-free. Department managers are responsible for creating procedures that ensure anti-virus software is run at regular intervals, and computers are verified as virus-free. Any activities with the intention to create and/or distribute malicious programs into <Company Name>'s networks (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.) are prohibited, in accordance with the Acceptable Use Policy . Refer to <Company Name>'s Anti-Virus Recommended Processes to help prevent virus problems. Noted exceptions: Machines with operating systems other than those based on Microsoft products are excepted at the current time.
  • As a minimum, you should have a password management policy or procedure which describes how often passwords are changed and how you track who has what passwords. Example text: All system-level passwords (e.g. root, enable, NT admin, application administration accounts, etc.) must be changed on at least a quarterly basis. All production system-level passwords must be part of the InfoSec administered global password management database. All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every six months. The recommended change interval is every four months. User accounts which have system-level privileges granted through group memberships or programs such as "sudo" must have a unique password from all other accounts held by that user.
  • These are just a few examples of the types of policies that may apply to different organization. The policy development area is certainly one area where .one size does not fit all.. The culture of the organization will have large impact on the types of policies that are implemented and how they are enforced.
  • Procedures are equally important as policies. Often the polices define what is to be protected and what are the ground rules. The procedures outline how to protect the resources or how to carry out the policies. For example, a Password Policy would outline password construction rules, rules on how to protect your password and how often to change them. The Password Management Procedure would outline the process to create new passwords, distribute them as well as the process for ensuring the passwords have changed on critical devices. There will not always be a one-to- one relationship between policy and procedures. In the next few pages we will review just a few of the important procedures that almost every organization needs.
  • The configuration management procedure would typically be defined at the department level or at the corporate level. Even if there is a corporate CM procedure, individual groups may choose to have their own. The CM procedure should define the process to document and request configuration changes of all scales (from a simple router installation to a major firewall ACL change). Ideally, there is a central group that review and approves of all change requests. A CM process is important for several key reasons: .Documents changes made. Provides an audit trail .Documents that possible system down-time so that when the change is made it is not seen as a system problem. .Provides a way to coordinate changes so that one change does not severely impact another change.
  • The backup and off-site storage policy may be required due to customer commitments. The number of people who can request off-site backup tapes should be kept to a minimum. You should try restoring from backup media on a regular basis to test integrity of backup methods. Part of the backup procedure may be in the form of a program or script which automates the process of performing backups.
  • A incident handling procedure is a definite must for all organizations. It is impossible to outline responses for all incidents, but you should cover the major types of incidents that might occur. Some example types might include: network port scan, denial of service attack, compromised host, compromised account, and inappropriate use. You should identify one person to act as a liaison to outside agencies.
  • Risk — The potential for harm or loss is best expressed as the answers to these four questions: What could happen? (What is the threat?) How bad could it be? (What is the impact or consequence?) How often might it happen? (What is the frequency?) How certain are the answers to the first three questions? (What is the degree of confidence?) The key element among these is the issue of uncertainty captured in the fourth question. If there is no uncertainty, there is no “risk” per se.
  • Threat agent – entities that wish to abuse or damage an asset Threat – is any potential danger to information, or systems (e.g. fire) Vulnerability – is a software, hardware, or procedural weakness that may provide an attacker the open door to enter a system. (e.g. lack of water) Risk – loss potential (probability) that a threat will exploit a vulnerability. Exposure – is an instance of being exposed to losses from a threat agent Safeguard - or countermeasure is something that mitigates the potential risk LIKELIHOOD of the threat occurring is the estimation of the probability that a threat will succeed in achieving an undesirable event.
  • 弱點指資產本身所存在之問題 , 例如 : 不穩定的電源 無保護網路線材 人員缺乏安全意識 不當的存取權限 損壞的門鎖
  • Wideband Delphi – group of experts meet to discuss risks; the coordinator formulates the problem and distributes to experts in the filed. The coordinator creates a scale to rank opinions and send the scale to experts. The experts create their list separately and they only know their position. The coordinator combines results and than everyone meets to discuss results – the experts lave and univocally resubmit changes. Process is repeat several times. Nominal Group Technique (NGT) each member of a small group (6-12) writes down what he or she thinks are the major issues. First person reads off one item form their list and item is recorded on a pad. Next person does the same and this continues in order until all lists are exhausted. Each member privately ranks the results and they are tabulated into one final ranked list. Builds on brainstorming, NGT. Identify all risks and look for commonalty and break those into major sub categories that are controllable.
  • Risk Analysis identifies risks that need to be controlled or accepted. Risk analysis for IT systems involves the analysis of asset values, threats, and vulnerabilities. The options presented below describe four different risk analysis approaches. Use the same baseline approach for all IT systems, irrespective of risks facing the systems, and accept that the level of security may not always be appropriate. Use an informal approach o perform risk analysis and concentrate on IT systems which are perceived as being exposed to high risks. Conduct detailed risk analysis using a formal approach for all IT systems. Carry out an initial “high level” risk analysis to identify IT systems exposed to high risks and those which are critical for the business, followed by a detailed risk analysis for these systems, and applying baseline security to all other systems
  • The objective of baseline approach is to establish a minimum set of safeguards to protect all or some IT systems of an organization. The appropriate baseline protection can be achieved through the use of safeguard catalogues which suggest a set of safeguards to protect an IT system against the most common threats. The level of baseline security can be adjusted to the needs of the organization Baseline protection is to select those parts of the safeguard catalogue which are relevant for the IT system considered. Several documents are already available which provide sets of baseline safeguards. For example, catalogues of baseline safeguards could be obtained from: International and national standards organizations, Industry sector standards or recommendations, or Some other company, preferably with similar business objectives, and of comparable size. An organization may also generate its own baseline, established commensurate with its typical environment, and with its business objectives. 6. Baseline approach: [Advantages] 1. Only a minimum amount of resources is needed for risk analysis and management for each safeguard implementation, and thus less time and effort is spent on selecting security safeguards, 2. Baseline safeguards may offer a cost-effective solution, as the same or similar baseline safeguards can be adopted for many systems without great effort if a large number of the organization’s systems operate in a common environment and if the security needs are comparable. [Disadvantages] 1. If the baseline level is set too high, there might be an excessive level of security on some IT systems, 2. If the level is set too low there may be a lack of security on some IT systems, resulting in a higher level of exposure, and 3. There might be difficulties in managing security relevant changes. For instance, if a system is upgraded, it might be difficult to assess whether the original baseline safeguards are still sufficient.
  • This option is to conduct informal pragmatic risk analyses. An informal approach is not based on structure methods, but exploits the knowledge and experience of individuals. 3. Informal Approach: [Advantages] 1. It usually does not require a lot of resources or time. 2. It is performed quicker than a detailed risk analysis. [Disadvantages] 1.Without some sort of formal approach or comprehensive checklists, the likelihood of missing some important details increases. 2. The results may be influenced by subjective views and the prejudices of the reviewer.
  • A detailed risk analysis for an IT system involves the identification of the related risks , and an assessment of their magnitude. Once a detailed risk analysis review for a system has been completed, the result of the review Asset and their values Threat, vulnerability, and risk levels Safeguards identified should be saved. 3. Detailed Approach: [Advantages] It is likely that appropriate safeguards are identified for all systems The results of the detailed analysis can be used in the management of security changes. [Disadvantages] It requires a considerable amount of time and effort, and expertise, to obtain results. 4. It is not advisable to use detailed risk analysis for all IT systems.
  • First it is necessary to conduct an initial high level risk analysis to identify which approach ( baseline or detailed approach ) is appropriate for each IT system. Input for the decision as to which approach is suitable for which IT system can be obtained from consideration of the following: The business values of the IT systems. This means the degree to which the organization’s business depends on the IT system. The level of investment in this system, in terms of developing, maintaining, or replacing the system. The asset’s value of the IT system, for which the organization directly assigns. Combined Approach [Advantages] The option, which is in a sense the combination of the best point of the baseline approach and the detailed approach. It provides a good balance between minimizing the time and effort spent in identifying safeguards, which still ensuring the high risk systems are appropriately protected [Disadvantages] As the initial risk analyses are at a high level, and potentially less accurate, some systems may not be identified as requiring detailed risk analysis.
  • Prior to gathering input for the asset identification and valuation, the boundaries of the review should be defined. A careful definition of boundaries at this stage avoids unnecessary work and improves the quality of the risk analysis. An asset is a component or part of a total system. All assets within the review boundary established must be identified. The asset type includes information/data, hardware, software, communications equipment, firmware, documents, image of the organization and etc.. After fulfilling the objective of asset identification by listing all assets of the IT system under review, values should be assigned to these assets. The values assigned should be related to the cost of obtaining and maintaining the asset, and potential adverse business impacts. Dependencies of assets on other assets should be identified, since this might influence the values of the assets. Identify the threat source (who and what causes the threat) and the threat target (i.e. what elements of the system may be affected by the threat). After that, it is necessary to assess the likelihood of the threats. This assessment includes identifying weaknesses in the assets, that may be exploited by a threat source to cause harm. A vulnerability which has no corresponding threat does not require the implementation of a safeguard, but should be recognized and monitored for changes. This assessment identifies vulnerabilities that may exploited by threats and assesses their likely level of weakness. Such existing and planned safeguards are identified as part of this process to avoid unnecessary work or cost. While identifying the existing safeguards, a check should be made to ensure that safeguards are working correctly. The result of this step is a list of all existing and planned safeguards, and their implementation and use status. The objective of this step is to identify and assess the risks to which the IT system and its assets are exposed. The value assigned to the assets, vulnerabilities and threats are combined to obtain values measuring the risk. A detailed consideration of the different types of risk analysis method will be explained later. The measures of the risks determined in the previous step should be used as the basis for identifying all safeguards that are necessary for appropriate protection. For the identification of safeguards it is useful to consider lessening the risks and cost factor. There are many constraints which can affect the selection of safeguards. These constraints must be taken into account when making recommendations and during the implementation. Typical constraints includes time constraints, financial constraints, technical constraints, sociological constraints, environment constraints, and legal constraints. After choosing the safeguards and identifying the reduction of risks these safeguards will achieve, there will always be residual risks- no system can be made absolutely secure. These residual risks should be categorized as ‘acceptable’ or ‘unacceptable’ for the organization. It is a management decision whether these risks will be accepted because of other constraints, or whether additional and maybe expensive safeguards are selected to reduce the unacceptable risks. The IT system security policy should contain details of safeguards required and describe why they are necessary. Then the IT security plan for the system deals with how to implement the selected safeguards.
  • Each KEYcontext uses the same four categories: Objective, Control, Implementation guidance , and Other information . why should information assets need to be protected? Information needs to be protected because modern organizations are faced with a wide range of security threats. These threats include everything from human error and equipment failure to theft, fraud, vandalism, sabotage, fire, flood, and even terrorism. And because most modern organizations operate in a complex, interconnected, technological world, information is also vulnerable to an entirely new set of high-tech threats and attacks. Because of their interconnectedness, modern organizations are also threatened by computer hackers, malicious code, and denial of service attacks. According to ISO17799, information can be protected using a wide variety of controls . In addition to hardware and software functions, controls include things like policies, procedures, processes, and organizational structures. In order to protect their information, organizations must develop, implement, monitor, evaluate, and improve these types of security controls. Taiwan rename iso 17799 to CNS 17799, CNS17800 for iso 27001(BS7799 part 2)
  • ISO 27001 asks you to select the Security Objectives and Security Controls (1 and 2 above) that address your unique security risks and requirements, and then to use this information to prepare what  ISO calls a Statement of Applicability . This Statement of Applicability is, in turn, used to prepare a detailed Risk Treatment Plan . Once you've implemented this Plan, you've established an ISMS, one that meets your organization's unique information security needs and requirements.
  • The 2002 version of the standard for the first time promoted the adoption of a process approach for the design and development of an ISMS. This approach, widely know as the Plan-Do-Check-Act (PDCA) model.
  • What is a risk assessment? This is the assessment of threats to, impacts on and vulnerabilities of information and information systems and processing facilities and the likelihood of their occurrence. What is risk management? This is the process of identifying, controlling and minimising or eliminating security risks that may affect information systems.
  • Information Technology: 1. TCSEC (Trusted computer System Evaluation Criteria) ,started from US. Army 1980. 2. ITSCE (Information Technology Security Evaluation Criteria). Defined by English, Germany, France and Dutch, Consider Confidential. 3. CC (common criteria) ISO/IEC 15408 at June 1999. Management process: 1.COBIT (Control Objectives for Information and Related Technology), proposed by Information System Audit and Control Association) 2.COSO (The Committee of Sponsoring Organization) , look at quality of financial report side.
  • Information Security For Protecting Business

    1. 2. “ How Secure is Your Corporation?&quot; <ul><li>One foot in ice water and one foot in boiling water does not mean that on average you are at room temperature . </li></ul><ul><ul><li>Corporations are not monolithic, and all parts of the business don’t have or need the same level of security </li></ul></ul><ul><ul><li>Security is not an end state, nor can it be judged by measuring any single variable at any single point in time </li></ul></ul>
    2. 3. Selling Security is Still a Challenge <ul><li>Is the glass half empty , or is it half full? </li></ul><ul><li>Security is like the brakes on your car. </li></ul><ul><ul><li>Their function is to slow you down </li></ul></ul><ul><ul><li>But their purpose is to allow you to go fast . </li></ul></ul><ul><ul><li>Bill Malick, Gartner </li></ul></ul>
    3. 4. Scope of Security <ul><li>System Security </li></ul><ul><li>- Mostly Technical Issues </li></ul><ul><li>- Hardware & Software Solutions, e.g.; </li></ul><ul><li>Cryptography, Protocol, Security System etc. </li></ul><ul><li>Information Security </li></ul><ul><li>- Mostly Managerial Issues </li></ul><ul><li>- Business Solutions, e.g.; </li></ul><ul><li>Organization, Culture (Behavior), Policy, </li></ul><ul><li>Risk Management, Standards, Legal Rights etc. </li></ul>
    4. 5. Causes of Information Damage
    5. 6. Information Security <ul><li>High dependence on information as a contributing factor of success or failure, created the need for information security and control </li></ul><ul><li>Information security definition: </li></ul><ul><li>“ preservation of confidentiality, integrity and availability of information and information systems” </li></ul><ul><li>The objective of information security is to ensure the continuity of business management and to reduce interruptions of business by preventing and minimizing the consequences of security incidents. Information security relates to all controls aimed at protecting the availability, integrity and confidentiality of information </li></ul>
    6. 7. Information Security Components Reliability C onfidentiality / Exclusivity I ntegrity A vailability The degree to which the organization can depend upon an information system for its provision of information
    7. 8. Business Model for Information Security Vulnerabilities Threats Legislation Identity Mgmt Assurance Controls Business Impacts Confidentiality Integrity Availability Assets Business Risks exposing To a loss of causing causing which are mitigated by which require causing exploit + which protect against reduce + +
    8. 9. Security Systems Development Life Cycle(SSDLC) <ul><li>A systematic way of providing information security </li></ul><ul><li>Phases: </li></ul><ul><li>-Phase 1: Investigation, including policy and procedure etc. </li></ul><ul><li>-Phase 2: Analysis, including risk management etc. </li></ul><ul><li>-Phase 3: Logical Design, including standards etc. </li></ul><ul><li>-Phase 4: Physical Design, including technology selection etc. </li></ul><ul><li>-Phase 5: Implementation </li></ul><ul><li>-Phase 6: Maintenance and Change </li></ul>
    9. 10. <ul><li>POLICY and PROCEDURE </li></ul>
    10. 11. Policy and Procedure <ul><li>A policy is typically a document that outlines specific requirements or rules that must be met. </li></ul><ul><li>In the information/network security realm, policies are usually point-specific, covering a single area. For example, an “Acceptable Use” policy would cover the rules and regulations for appropriate use of the computing facilities. </li></ul><ul><li>A standard is typically a collections or system-specific or procedural-specific requirements that must be meet by everyone. </li></ul><ul><ul><li>For example, you might have a standard that describes to how to harden a Windows NT workstation for placement on an external (DMZ) network. </li></ul></ul><ul><ul><li>People must follow this standard exactly if they wish to install a Windows NT workstation on an external network segment. </li></ul></ul><ul><li>A guideline is typically a collection of system specific or procedural specific “suggestions” for best practice. </li></ul><ul><ul><li>They are not requirements to be met, but are strongly recommended. </li></ul></ul><ul><li>Effective security policies make frequent references to standards and guidelines that exist within an organization. </li></ul>
    11. 12. A Security Policy Framework <ul><li>Policies define appropriate behavior. </li></ul><ul><li>Policies set the stage in terms of what tools and procedures are needed. </li></ul><ul><li>Policies communicate a consensus. </li></ul><ul><li>Policies provide a foundation for HR action in response to inappropriate behavior. </li></ul><ul><li>Policies may help prosecute cases. </li></ul>
    12. 13. Importance of Security Policies <ul><li>Security policies are an absolute must for any organization. </li></ul><ul><li>They provide the virtual glue to hold it all together. </li></ul><ul><li>Policies lay the ground-work. </li></ul><ul><li>Imagine a small city that did not have any rules? What would life be like? The same applies to your organization . </li></ul>
    13. 14. Who and What to Trust <ul><li>Trust is a major principle underlying the development of security policies. </li></ul><ul><li>Initial step is to determine who gets access. </li></ul><ul><li>Deciding on level of trust is a delicate balancing act. </li></ul><ul><li>Too much trust may lead to eventual security problems </li></ul><ul><li>Too little trust may make it difficult to find and keep employees or get jobs done </li></ul><ul><li>How much should you trust people regarding to their access or usage of computer and network resources? </li></ul>
    14. 15. Possible Trust Models <ul><li>Trust everyone all of the time: </li></ul><ul><ul><li>easiest to enforce, but impractical </li></ul></ul><ul><ul><li>one bad apple can ruin the whole barrel </li></ul></ul><ul><li>Trust no one at no time: </li></ul><ul><ul><li>most restrictive, but also impractical </li></ul></ul><ul><ul><li>difficult to staff positions </li></ul></ul><ul><li>Trust some people some of the time: </li></ul><ul><ul><li>exercise caution in amount of trust given </li></ul></ul><ul><ul><li>access is given out as needed </li></ul></ul><ul><ul><li>technical controls are needed to ensure trust is not violated </li></ul></ul>
    15. 16. Why the Political Turmoil? <ul><li>People view policies as: </li></ul><ul><ul><li>an impediment to productivity </li></ul></ul><ul><ul><li>measures to control behavior </li></ul></ul><ul><li>People have different views about the need </li></ul><ul><li>for security controls. </li></ul><ul><li>People fear policies will be difficult to follow </li></ul><ul><li>and implement. </li></ul><ul><li>Policies affect everyone within the </li></ul><ul><li>organization. </li></ul>
    16. 17. Who Should Be Concerned? <ul><li>Users - policies will affect them the most. </li></ul><ul><li>System support personnel - they will be required to implement, comply with and support the policies. </li></ul><ul><li>Managers - they are concerned about protection of data and the associated cost of the policy. </li></ul><ul><li>Company lawyers and auditors - they are concerned about company reputation, responsibility to clients/customers. </li></ul>
    17. 18. The Policy Design Process <ul><li>Choose the policy development team. </li></ul><ul><li>Designate a person or a group to serve as the official policy interpreter. </li></ul><ul><li>Decide on the scope and goals of the policy. </li></ul><ul><ul><li>Scope should be a statement about who is covered by the policy. </li></ul></ul><ul><li>Decide on how specific to make the policy </li></ul><ul><ul><li>not meant to be a detailed implementation plan </li></ul></ul><ul><ul><li>don ’ t include facts which change frequently </li></ul></ul>
    18. 19. The Policy Design Process <ul><li>A sample of people affected by the policy should be provided an opportunity to review and comment . </li></ul><ul><li>A sampling of the support staff effected by policy should have an opportunity to review it. </li></ul><ul><li>Incorporate policy awareness as a part of employee orientation. </li></ul><ul><li>Provide a refresher overview course on policies once or twice a year. </li></ul>
    19. 20. Basic Policy Requirements <ul><li>Policies must: </li></ul><ul><ul><li>be implementable and enforceable </li></ul></ul><ul><ul><li>be concise and easy to understand </li></ul></ul><ul><ul><li>balance protection with productivity </li></ul></ul><ul><li>Policies should: </li></ul><ul><ul><li>state reasons why policy is needed </li></ul></ul><ul><ul><li>describe what is covered by the policies </li></ul></ul><ul><ul><li>define contacts and responsibilities </li></ul></ul><ul><ul><li>discuss how violations will be handled </li></ul></ul>
    20. 21. Level of Control <ul><li>Security needs and culture play major role. </li></ul><ul><li>Security policies MUST balance level of control with level of productivity. </li></ul><ul><li>If policies are too restrictive, people will find ways to circumvent controls. </li></ul><ul><li>Technical controls are not always possible. </li></ul><ul><li>You must have management commitment on the level of control. </li></ul>
    21. 22. Policy Structure <ul><li>Dependent on company size and goals. </li></ul><ul><li>One large document or several small ones? </li></ul><ul><ul><li>smaller documents are easier to maintain/update </li></ul></ul><ul><li>Some policies appropriate for every site, others are specific to certain environments. </li></ul><ul><li>Some key policies: </li></ul><ul><ul><li>acceptable use </li></ul></ul><ul><ul><li>remote access </li></ul></ul><ul><ul><li>information protection </li></ul></ul><ul><ul><li>perimeter security </li></ul></ul><ul><ul><li>baseline host/device security </li></ul></ul>
    22. 23. The Acceptable Use Policy <ul><li>Discusses and defines the appropriate use of the computing resources. </li></ul><ul><li>Users should be required to read and sign account usage policy as part of the account request process. </li></ul><ul><li>A key policy that all sites should have. </li></ul>
    23. 24. Remote Access Policy <ul><li>Outlines and defines acceptable methods of remotely connecting to the internal network. </li></ul><ul><li>Essential in large organization where networks are geographically dispersed and even extend into the homes. </li></ul><ul><li>Should cover all available methods to remotely access internal resources: </li></ul><ul><ul><li>dial-in (SLIP, PPP) </li></ul></ul><ul><ul><li>ISDN/frame relay </li></ul></ul><ul><ul><li>telnet/ssh access from internet </li></ul></ul><ul><ul><li>cable modem/VPN/DSL </li></ul></ul>
    24. 25. Information Protection Policy <ul><li>Provides guidelines to users on the processing, storage and transmission of sensitive information. </li></ul><ul><li>Main goal is to ensure information is appropriately protected from modification or disclosure. </li></ul><ul><li>May be appropriate to have new employees sign policy as part of their initial orientation. </li></ul><ul><li>Should define sensitivity levels of information. </li></ul>
    25. 26. The Perimeter Security Policy <ul><li>Describes, in general, how perimeter security is maintained. </li></ul><ul><li>Describes who is responsible for maintaining it. </li></ul><ul><li>Describes how hardware and software changes to perimeter security devices are managed and how changes are requested and approved. </li></ul>
    26. 27. Virus Protection and Prevention Policy <ul><li>Provides baseline requirements for the use of virus protection software. </li></ul><ul><li>Provides guidelines for reporting and containing virus infections. </li></ul><ul><li>Provides guidelines for several levels of virus risk. </li></ul><ul><li>Should discuss requirements for scanning email attachments. </li></ul><ul><li>Should discuss policy for the download and installation of public domain software. </li></ul>
    27. 28. Virus Protection and Prevention Policy <ul><li>Should discuss frequency of virus data file updates. </li></ul><ul><li>Should discuss testing procedures for installation of new software. </li></ul>
    28. 29. Password Policy <ul><li>Provides guidelines for how user level and system level passwords are managed and changed. </li></ul><ul><li>Discusses password construction rules. </li></ul><ul><li>Provides guidelines for how passwords are protected from disclosure. </li></ul><ul><li>Discusses application development guidelines for when passwords are needed. </li></ul><ul><li>Discusses the use of SNMP community strings and pass-phrases. </li></ul>
    29. 30. Other Important Policies <ul><li>A policy which addresses forwarding of email to offsite addresses. </li></ul><ul><li>A policy which addresses wireless networks. </li></ul><ul><li>A policy which addresses baseline lab security standards. </li></ul><ul><li>A policy which addresses baseline router configuration parameters. </li></ul><ul><li>A policy which addresses requirements for installing devices on a dirty network. </li></ul>
    30. 31. Security Procedures <ul><li>Policies only define &quot;what&quot; is to be protected. </li></ul><ul><li>Procedures define &quot;how&quot; to protect resources and are the mechanisms to enforce policy. </li></ul><ul><li>Procedures define detailed actions to take for specific incidents. </li></ul><ul><li>Procedures provide a quick reference in times of crisis. </li></ul><ul><li>Procedures help eliminate the problem of a single point of failure (e.g., an employee suddenly leaves or is unavailable in a time of crisis). </li></ul>
    31. 32. Configuration Management Procedure <ul><li>Defines how new hardware/software is tested and installed. </li></ul><ul><li>Defines how hardware/software changes are documented. </li></ul><ul><li>Defines who must be informed when hardware and software changes occur. </li></ul><ul><li>Defines who has authority to make hardware and software configuration changes. </li></ul>
    32. 33. Data Backup and Off-site Storage Procedures <ul><li>Defines which file systems are backed up. </li></ul><ul><li>Defines how often backups are performed. </li></ul><ul><li>Defines how often storage media is rotated. </li></ul><ul><li>Defines how often backups are stored off-site. </li></ul><ul><li>Defines how storage media is labeled and documented. </li></ul>
    33. 34. Incident Handling Procedure <ul><li>Defines how to handle anomaly investigation and intruder attacks. </li></ul><ul><li>Defines areas of responsibilities for members of the response team. </li></ul><ul><li>Defines what information to record and track. </li></ul><ul><li>Defines who to notify and when. </li></ul><ul><li>Defines who can release information and the procedure for releasing the information. </li></ul><ul><li>Defines how a follow-up analysis should be performed and who will participate. </li></ul>
    34. 35. <ul><li>RISK MANAGEMENT </li></ul>
    35. 36. Risk <ul><li>Risk is the likelihood of the occurrence of </li></ul><ul><li>a vulnerability multiplied by the value of </li></ul><ul><li>the information asset minus the percentage </li></ul><ul><li>of risk mitigated by current controls plus </li></ul><ul><li>the uncertainty of current knowledge of the </li></ul><ul><li>vulnerability </li></ul>
    36. 37. What is Risk <ul><li>A definable event </li></ul><ul><li>Probability of occurrence </li></ul><ul><li>Impact of occurrence </li></ul><ul><li>A risk occurs when the problem happens </li></ul><ul><li>Loss expectancy that a threat might exploit a vulnerability. </li></ul>
    37. 38. Relationship among different security components Threat Agent Threat Vulnerability RISK Exposure Safeguard Gives rise to Exploits Leads to Can damage And causes an Can be counter measured by a Directly affects Asset
    38. 39. Risk Well-Formed Risk Statement Impact What is the impact to the business? Probability How likely is the threat given the controls? Asset What are you trying to protect? Threat What are you afraid of happening? Vulnerability How could the threat occur? Mitigation What is currently reducing the risk?
    39. 40. Vulnerability Identification <ul><li>Vulnerability – is a software, hardware, or procedural weakness that may provide an attacker the open door to enter a system. </li></ul><ul><li>Specific avenues threat agents can exploit to attack an information asset are called vulnerabilities </li></ul><ul><li>Examine how each threat could be perpetrated and list organization ’ s assets and vulnerabilities </li></ul><ul><li>Process works best when people with diverse backgrounds within organization work iteratively in a series of brainstorming sessions </li></ul><ul><li>At the end of risk identification process, list of assets and their vulnerabilities is achieved </li></ul>
    40. 41. Risk Mitigation <ul><li>Understand security risk </li></ul><ul><li>Understand technology </li></ul><ul><li>Accept Risk </li></ul><ul><ul><li>Documentation of risk acceptance is a form of mitigation. </li></ul></ul><ul><li>Defer or transfer risk </li></ul><ul><ul><li>Insurance </li></ul></ul><ul><li>Mitigate risk </li></ul><ul><ul><li>Technology can mitigate risk </li></ul></ul>
    41. 42. <ul><li>Risk Management Process </li></ul>
    42. 43. How to Develop a Security Risk Management Process? <ul><li>Security risk management process: </li></ul><ul><ul><li>A process for identifying, prioritizing, and managing risk to an acceptable level within the organization </li></ul></ul><ul><li>Developing a formal security risk management process must address the following: </li></ul><ul><ul><li>Threat response time </li></ul></ul><ul><ul><li>Regulatory compliance </li></ul></ul><ul><ul><li>Infrastructure management costs </li></ul></ul><ul><ul><li>Risk identification and assessment (prioritization) </li></ul></ul>
    43. 44. Successful Factors for Security Risk Management Process <ul><li>Key factors to implementing a successful security risk management process include: </li></ul><ul><ul><li>Executive sponsorship </li></ul></ul><ul><ul><li>Well-defined list of risk management stakeholders </li></ul></ul><ul><ul><li>Organizational maturity in terms of risk management </li></ul></ul><ul><ul><li>An atmosphere of open communications and teamwork </li></ul></ul><ul><ul><li>A holistic view of the organization </li></ul></ul><ul><ul><li>Security risk management team’s authority </li></ul></ul>
    44. 45. Risk Management Process Implementing Controls 3 Conducting Decision Support 2 Measuring Program Effectiveness 4 Assessing Risk 1
    45. 46. Risk Assessment Flowchart Step 1. System Characterization Input Risk Assessment Activities Output Step 2. Threat Identification Step 3. Vulnerability Identification Step 4. Control Analysis Step 5. Likelihood Determination Step 6. Impact Analysis • Loss of Integrity • Loss of Availability • Loss of Confidentiality Step 7. Risk Determination Step 8.Control Recommendations Step 9.Results Documentation • Hardware / Software • System interfaces • Data and information • People • System mission • History of system attack • Data from intelligence agencies, NIPC, OIG,FedCIRC, mass media, • Reports from prior risk assessments • Any audit comments • Security requirements • Security test results • Mission impact analysis • Asset criticality assessment • Data criticality • Data sensitivity • Current controls • Planned controls • Threat-source motivation • Threat capacity • Nature of vulnerability • Current controls • System Boundary • System Functions • System and Data Criticality • System and Data Sensitivity Impact Rating Threat Statement List of Potential Vulnerabilities List of Current and Planned Controls Likelihood Rati ng • Likelihood of threat exploitation • Magnitude of impact • Adequacy of planned or current controls Risks and Associated Risk Levels Recommended Controls Risk Assessment Report
    46. 47. Risk Mitigation Flowchart Input Risk Mitigation Activities Output Step 1. Prioritize Actions Step 2. Evaluate Recommended Control Options • Associated costs • Feasibility Step 3. Conduct Cost-Benefit Analysis • Impact of implementing • Impact of not implementing • Associated costs Step 4. Select Controls Step 5. Assign Responsibility Step 6. Develop Safeguard Implementation Plan • Risks and Associated Risk Levels • Prioritized Actions • Recommended Controls • Selected Planned Controls • Responsible Persons • Start Date • Target Completion Date • Maintenance Requirements Step 7 .Implement Selected Controls • Risk levels from the risk assessment report • Risk assessment report Actions ranking from High to Low Safeguard implementation plan List of possible controls Cost-benefit analysis Selected Controls List of responsible persons Residual Risks
    47. 48. <ul><li>Risk Analysis Method </li></ul>
    48. 49. Risk Management Risk Analysis (Identification + Assessment) Goal <ul><li>Manage risks across business to acceptable level </li></ul><ul><li>Identify and prioritize risks </li></ul>Cycle <ul><li>Overall program across all four phases </li></ul><ul><li>Single phase of risk management program </li></ul>Schedule <ul><li>Scheduled activity </li></ul><ul><li>Continuous activity </li></ul>Alignment <ul><li>Aligned with budgeting cycles </li></ul><ul><li>Not applicable </li></ul>
    49. 50. Risk Analysis Method <ul><li>Two types of risk analysis: </li></ul><ul><ul><li>Quantitative – attempts to assign real numbers to the costs of safeguards and the amount of damage that can take place </li></ul></ul><ul><ul><li>Qualitative – An analysis that judges an organization’s risk to threats, which is based on judgment, intuition, and the experience versus assigning real numbers to this possible risks and their potential loss; e.g., </li></ul></ul><ul><ul><li>Analytical Hierarchy Process (AHP) </li></ul></ul>
    50. 51. Steps of Quantitative Risk Analysis <ul><li>Assign value to information assets (tangible and intangible) </li></ul><ul><li>Estimate potential loss per risk </li></ul><ul><li>Perform a threat analysis </li></ul><ul><li>Derive the overall loss potential per risk </li></ul><ul><li>Choose safeguards / countermeasure for each risk </li></ul><ul><li>Determine risk response (e.g. mitigation, avoidance, acceptance) </li></ul>
    51. 52. Quantitative Risk Analysis <ul><li>Exposure Factor ( EF ) = Percentage of asset loss caused by identified threat; ranges from 0 to 100% </li></ul><ul><li>Single Loss Expectancy ( SLE ) = Asset Value x Exposure Factor; 1,000,000 @ 10% likelihood = $100,000 </li></ul><ul><li>Annualized Rate of Occurrence ( ARO ) = Estimated frequency a threat will occur with in a year and is characterized on an annual basis. A threat occurring once in 10 years has an ARO of 0.1; a threat occurring 50 times in a year has an ARO of 50 </li></ul><ul><li>Annualized Loss Expectancy ( ALE ) = Single Loss Expectancy x Annualized Rate of Occurrence </li></ul><ul><li>Safeguard cost/benefit analysis = (ALE before implementing safeguard) – (ALE after implementing safeguard) – (annual cost of safeguard) == value of safeguard to the company </li></ul>
    52. 53. Quantitative Risk Analysis - Summary <ul><li>Pros </li></ul><ul><ul><li>Uses probability concepts – the likelihood that an risk will occur or will not occur </li></ul></ul><ul><ul><li>The value of information is expressed in monetary terms with supporting rationale </li></ul></ul><ul><ul><li>Risk assessment results are derived and expressed in management speak </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Purely quantitative risk analysis not possible because quantitative measures must be applied to qualitative elements </li></ul></ul><ul><ul><li>Can be less ambiguous but using numbers can give appearance of specificity that does not really exist </li></ul></ul><ul><ul><li>Huge amount of data must be gathered and managed </li></ul></ul>
    53. 54. Qualitative Risk Analysis <ul><li>Does not assign numbers and monetary value to components and losses. </li></ul><ul><li>Walks through different scenarios of risk possibilities and rank the seriousness of the threats for the sensitivity of the assets. </li></ul>
    54. 55. Identifying Qualitative Risks <ul><li>Expert Interviews </li></ul><ul><li>Brainstorming </li></ul><ul><li>Nominal Group Technique </li></ul><ul><li>Affinity Diagram </li></ul><ul><li>Analogy Techniques </li></ul>
    55. 57. 100% 4 12 Example Qualitative Risk Matrix  Hostage / Kidnap Strike / Walkout Hostile Takeover Major Explosion  Terrorism Industrial Espionage 0%  Sabotage Comm. Disease Flood  Suicide Telecomm Failure . Maj. Operator Error  Child Care Incident Transportation Incident  Minor Explosion  Neighbor Issue  Civil Unrest   Employee Violence  Tornado  Breach IT Security Organized Crime   Blizzard  Bribery / Extortion Protesters Injury / Death Accusation / Libel / Slander  Fog  Bomb Threat Equipment Malfunc. Power Failure  Ice Storm   Media Investigation Chemical Spill / Contamination   Major Fire Class Action Lawsuit   Management Issues  Security Breach Loss of IT / Virus   Major Electrical Storm HIGH RISK LOW RISK MEDIUM HIGH MEDIUM LOW
    56. 58. Qualitative Risk Analysis - Summary <ul><li>Pros </li></ul><ul><ul><li>Is simple and readily understood and executed. </li></ul></ul><ul><ul><li>Provides a general indication of significant areas of risk that should be addressed </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Is difficult to enforce in uniformity and consistency but provides some order of measurement </li></ul></ul><ul><ul><li>Is subjective in both process and metrics. </li></ul></ul><ul><ul><li>Can not provide cost/benefit analysis </li></ul></ul>
    57. 59. Quantitative versus Qualitative Quant. Attributes Qual. + Independent & Objective Metrics - + Cost / Benefit analysis - + Monetary based - - Amount of work, cost, time + - Amount of information required + + Easily automated - - Degree of guesswork + + Value of information understood - + Threat frequency and impact data required -
    58. 60. <ul><li>Corporate Risk Analysis Strategy </li></ul>
    59. 61. Corporate Risk Analysis Strategy Corporate Risk Analysis Strategy Baseline Approach Informal Approach Detailed Approach Combined Approach Combined Approach High Level Risk Analysis Detailed Risk Analysis Baseline Approach Selection of Safeguards Risk Acceptance IT System Security Policy IT Security Plan
    60. 62. Baseline Approach <ul><li>Establish a minimum set of safeguards to protect all or some IT systems of an organization </li></ul><ul><li>Achieved through the use of safeguard catalogues which suggest a set of safeguards to protect an IT system against the most common threats </li></ul><ul><li>The level of baseline security can be adjusted to the needs of the organization </li></ul>Advantages Disadvantages 1. Minimum amount of resources 2. Cost-effective 1. Excessive level of security 2. A lack of security 3. Security relevant changes
    61. 63. Informal Approach <ul><li>Conduct informal pragmatic risk analysis </li></ul><ul><li>Exploit the knowledge and experience of individuals </li></ul>Advantages Disadvantages 1. Not require a lot of resources or time 2. Quicker than a detailed risk analysis 1. Missing some important details 2. Influenced by subjective views
    62. 64. Detailed Approach <ul><li>Involves the identification of the related risks , and an assessment of their magnitude for all IT systems </li></ul><ul><li>The result of the analysis should be saved </li></ul><ul><ul><li>Asset and their values </li></ul></ul><ul><ul><li>Threat, vulnerability, and risk levels </li></ul></ul><ul><ul><li>Safeguards identified </li></ul></ul>Advantages Disadvantages 1. Appropriate safeguards are identified for all systems 2. Management of security changes 1. A considerable amount of time, effort, and expertise
    63. 65. Combined Approach <ul><li>First it is necessary to conduct an initial high level risk analysis to identify which approach ( baseline or detailed approach ) is appropriate for each IT system </li></ul><ul><li>Input for the decision as to which approach is suitable for which IT system: </li></ul><ul><ul><li>The business values of the IT systems </li></ul></ul><ul><ul><li>The level of investment in this IT system </li></ul></ul><ul><ul><li>The asset’s value of the IT system </li></ul></ul>Advantages Disadvantages <ul><li>1. Provide a good balance between </li></ul><ul><ul><li>(1) Minimizing the time and effort spent in identifying safeguards </li></ul></ul><ul><ul><li>(2) Ensuring the high risk systems are appropriately protected. </li></ul></ul>1. Some systems may not be identified as requiring detailed risk analysis
    64. 66. The Process of Risk Analysis Establishment of Review Boundary Identification of Assets Valuation of Assets and Establishment of Dependencies Between Assets Threat Assessment Vulnerability Assessment Identification of Existing/Planning Safeguards Assessment of Risks Selection of Safeguards Risk Acceptance IT System Security Policy IT Security Plan Identification Review of Constraints No Yes Detailed Approach Risk Management
    65. 67. <ul><li>INFORMATION SECURITY STANDARD </li></ul>
    66. 68. Introduction <ul><li>ISO 17799/BS 7799-1 is an international standard that sets out the requirements of good practice for Information Security Management.   </li></ul><ul><li>ISO 27001/BS 7799-2 defines the specification for an Information Security Management System (ISMS).   </li></ul><ul><li>- The scope of an ISMS includes: </li></ul>people proc e sses IT Systems Policies
    67. 69. History of ISMS Standards ISO17799:2000 International BS7799-1:1999 BS7799-2:1999 UK BS7799-Part 2: 2002 BS7799-1:2000 ISO17799:2005 ISO27001:2005 BS7799:19 95 = copy/translation = revision
    68. 70. What is BS7799-1 / ISO 17799? <ul><li>The goal of BS7799-1 / ISO 17799 is to “ provide a common base for developing organizational security standards and effective security management practice and to provide confidence in inter-organizational dealings. ” </li></ul>
    69. 71. Who is BS7799-1/ISO 17799 for? <ul><li>BS7799-1 / ISO 17799 meets the needs of organizations and companies of all types, both private and public. </li></ul><ul><li>For any organization that stores confidential information on internal or external systems, depends on such systems to run its operations, or indeed wishes to demonstrate its information security by conforming to a known standard, BS7799-1 / ISO 17799 would be of very great interest. </li></ul>
    70. 72. The Eleven Key Context of ISO 17799 <ul><li>Security policy - This provides management direction and support for information security </li></ul><ul><li>Organization of information security - To help you manage information security within the organization </li></ul><ul><li>Asset management - To help you identify your assets and appropriately protect them </li></ul><ul><li>Human resources security - To reduce the risks of human error, theft, fraud or misuse of facilities </li></ul><ul><li>Physical and environmental security - To prevent unauthorized access, damage and interference to business premises and information </li></ul><ul><li>Communications and operations management - To ensure the correct and secure operation of information processing facilities </li></ul>
    71. 73. The Eleven Key Context of ISO 17799 (cont’d) <ul><li>Access control - To control access to information </li></ul><ul><li>Information systems acquisition, development and maintenance - To ensure that security is built into information systems </li></ul><ul><li>Information security incident management-To make sure that all information security events and weaknesses can be reported and solve effectively. </li></ul><ul><li>Business continuity management - To counteract interruptions to business activities and to protect critical business processes from the effects of major failures or disasters </li></ul><ul><li>Compliance - To avoid breaches of any criminal and civil law, statutory, regulatory or contractual obligations, and any security requirement </li></ul>
    72. 74. Information Security Management System (ISMS) <ul><li>Definition: </li></ul><ul><li>that part of the overall management system, based on a business risk approach, to </li></ul><ul><ul><li>establish, </li></ul></ul><ul><ul><li>implement, </li></ul></ul><ul><ul><li>operate, </li></ul></ul><ul><ul><li>monitor, </li></ul></ul><ul><ul><li>maintain and </li></ul></ul><ul><ul><li>improve information security </li></ul></ul><ul><li>The management system includes organizational structure, policies, planning activities, responsibilities, practices, procedures, processes and resources </li></ul>
    73. 75. Plan-Do-Check-Act Cycle (PDCA) Development, Maintenance and Improvement cycle Interested parties Interested parties Establish ISMS Context & Risk Assessment Plan Design and Implement ISMS Do Maintain and Improve the ISMS Act Monitor and Review ISMS Check Information security requirements and expectations Managed information security
    74. 76. <ul><li>Establish the ISMS </li></ul><ul><li>Define the scope of the ISMS </li></ul><ul><li>Define an ISMS policy </li></ul><ul><li>Define a systematic approach to risk management </li></ul><ul><li>Identify the risks </li></ul><ul><li>Assess the risks </li></ul><ul><li>Identify and evaluate options for the treatment of risks </li></ul><ul><li>Select control objectives and controls for the treatment of risks </li></ul><ul><li>Prepare a Statement of Applicability </li></ul><ul><li>Obtain management approval for residual risks and authorization to implement and operate the ISMS </li></ul>P DCA
    75. 77. <ul><li>Implement and operate the ISMS </li></ul><ul><li>Formulate a risk treatment plan and its documentation, including planned process and detailed procedures </li></ul><ul><li>Implement the risk treatment plan planned controls </li></ul><ul><li>Implement training and awareness programs </li></ul><ul><li>Manage operations and resources </li></ul><ul><li>Implement procedures and controls to detect and response to security incidents </li></ul>P D CA
    76. 78. <ul><li>Monitor and review the ISMS </li></ul><ul><li>Execute monitoring procedures </li></ul><ul><li>Undertake regular reviews </li></ul><ul><li>Review level of residual risk </li></ul><ul><li>Conduct internal audits </li></ul><ul><li>Undertake a management review </li></ul><ul><li>Record actions and events </li></ul>PD C A
    77. 79. <ul><li>Maintain and improve the ISMS </li></ul><ul><li>Implement the identified improvements </li></ul><ul><li>Take appropriate corrective and preventive actions </li></ul><ul><li>Communicate results </li></ul><ul><li>Ensure effectiveness </li></ul>PDC A
    78. 80. ISO27001 versus ISO17799 <ul><li>ISO27001 </li></ul><ul><li>formal standard </li></ul><ul><li>certification possible </li></ul><ul><li>requirements for a management system </li></ul><ul><li>requirements for controls (if applicable) </li></ul><ul><li>ISO 17799 </li></ul><ul><li>code of practice (set of best practices) </li></ul><ul><li>implementation advice and guidance </li></ul>
    79. 81. What are ISO 17799 and ISO 27001 not <ul><ul><li>limited to information technology </li></ul></ul><ul><ul><li>a security checklist </li></ul></ul><ul><ul><li>an insurance policy against security breaches </li></ul></ul><ul><ul><li>an audit method </li></ul></ul><ul><ul><li>a risk analysis method </li></ul></ul>