1 / 84

Information Security and Its Impact on Business

Information Security and Its Impact on Business. Prof. Chi-Chun Lo National Chiao-Tung University Oct. 5, 2006. INTRODUCTION. What if someone asks your CEO “How Secure is Your Corporation?".

Download Presentation

Information Security and Its Impact on Business

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Information Security and Its Impact on Business Prof. Chi-Chun Lo National Chiao-Tung University Oct. 5, 2006

  2. INTRODUCTION

  3. What if someone asks your CEO “How Secure is Your Corporation?" • One foot in ice water and one foot in boiling water does not mean that on average you are at room temperature. • Corporations are not monolithic, and all parts of the business don’t have (or necessarily need) the same level of security • Security is not an end state, nor can it be judged by measuring any single variable at any single point in time

  4. Selling Security is Still a Challenge • Is the glass half empty, or is it half full? • Security is like the brakes on your car. • Their function is to slow you down • But their purpose is to allow you to go fast. Bill Malick, Gartner

  5. Scope of Security • System Security - Mostly Technical Issues - Hardware & Software Solutions, e.g.; Cryptography, Protocol, Security System etc. • Information Security - Mostly Managerial Issues - Business Solutions, e.g.; Organization, Culture (Behavior), Policy, Risk Management, Standards, Legal Rights etc.

  6. Causes of Information Damage

  7. Information Security • High dependence on information as a contributing factor of success or failure, created the need for information security and control • Information security definition: “preservation of confidentiality, integrity and availability of information and information systems” • 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

  8. Information Security Components Confidentiality / Exclusivity Integrity Reliability Availability The degree to which the organization can depend upon an information system for its provision of information

  9. Business Model for Information Security exposing To a loss of Assets Confidentiality Integrity Availability Vulnerabilities + Business Risks + exploit causing causing + Business Impacts Threats reduce Legislation Controls which protect against which are mitigated by causing which require Identity Mgmt Assurance

  10. Security Systems Development Life Cycle(SSDLC) • A systematic way of providing information security • Phases: -Phase 1: Investigation, including policy and procedure etc. -Phase 2: Analysis, including risk management etc. -Phase 3: Logical Design, including standards etc. -Phase 4: Physical Design, including technology selection etc. -Phase 5: Implementation -Phase 6: Maintenance and Change

  11. POLICY and PROCEDURE

  12. Policy and Procedure • A policy is typically a document that outlines specific requirements or rules that must be met. • 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. • A standard is typically a collections or system-specific or procedural-specific requirements that must be meet by everyone. • For example, you might have a standard that describes to how to harden a Windows NT workstation for placement on an external (DMZ) network. • People must follow this standard exactly if they wish to install a Windows NT workstation on an external network segment. • A guideline is typically a collection of system specific or procedural specific “suggestions” for best practice. • They are not requirements to be met, but are strongly recommended. • Effective security policies make frequent references to standards and guidelines that exist within an organization.

  13. A Security Policy Framework • Policies define appropriate behavior. • Policies set the stage in terms of what tools and procedures are needed. • Policies communicate a consensus. • Policies provide a foundation for HR action in response to inappropriate behavior. • Policies may help prosecute cases.

  14. Importance of Security Policies • Security policies are an absolute must for any organization. • They provide the virtual glue to hold it all together. • Policies lay the ground-work. • Imagine a small city that did not have any rules? What would life be like? The same applies to your organization .

  15. Who and What to Trust • Trust is a major principle underlying the development of security policies. • Initial step is to determine who gets access. • Deciding on level of trust is a delicate balancing act. • Too much trust may lead to eventual security problems • Too little trust may make it difficult to find and keep employees or get jobs done • How much should you trust people regarding to their access or usage of computer and network resources?

  16. Possible Trust Models • Trust everyone all of the time: • easiest to enforce, but impractical • one bad apple can ruin the whole barrel • Trust no one at no time: • most restrictive, but also impractical • difficult to staff positions • Trust some people some of the time: • exercise caution in amount of trust given • access is given out as needed • technical controls are needed to ensure trust is not violated

  17. Why the Political Turmoil? • People view policies as: • an impediment to productivity • measures to control behavior • People have different views about the need for security controls. • People fear policies will be difficult to follow and implement. • Policies affect everyone within the organization.

  18. Who Should Be Concerned? • Users - policies will affect them the most. • System support personnel - they will be required to implement, comply with and support the policies. • Managers - they are concerned about protection of data and the associated cost of the policy. • Company lawyers and auditors - they are concerned about company reputation, responsibility to clients/customers.

  19. The Policy Design Process • Choose the policy development team. • Designate a person or a group to serve as the official policy interpreter. • Decide on the scope and goals of the policy. • Scope should be a statement about who is covered by the policy. • Decide on how specific to make the policy • not meant to be a detailed implementation plan • don’t include facts which change frequently

  20. The Policy Design Process • A sample of people affected by the policy should be provided an opportunity to review and comment. • A sampling of the support staff effected by policy should have an opportunity to review it. • Incorporate policy awareness as a part of employee orientation. • Provide a refresher overview course on policies once or twice a year.

  21. Basic Policy Requirements • Policies must: • be implementable and enforceable • be concise and easy to understand • balance protection with productivity • Policies should: • state reasons why policy is needed • describe what is covered by the policies • define contacts and responsibilities • discuss how violations will be handled

  22. Level of Control • Security needs and culture play major role. • Security policies MUST balance level of control with level of productivity. • If policies are too restrictive, people will find ways to circumvent controls. • Technical controls are not always possible. • You must have management commitment on the level of control.

  23. Policy Structure • Dependent on company size and goals. • One large document or several small ones? • smaller documents are easier to maintain/update • Some policies appropriate for every site, others are specific to certain environments. • Some key policies: • acceptable use • remote access • information protection • perimeter security • baseline host/device security

  24. The Acceptable Use Policy • Discusses and defines the appropriate use of the computing resources. • Users should be required to read and sign account usage policy as part of the account request process. • A key policy that all sites should have.

  25. Remote Access Policy • Outlines and defines acceptable methods of remotely connecting to the internal network. • Essential in large organization where networks are geographically dispersed and even extend into the homes. • Should cover all available methods to remotely access internal resources: • dial-in (SLIP, PPP) • ISDN/frame relay • telnet/ssh access from internet • cable modem/VPN/DSL

  26. Information Protection Policy • Provides guidelines to users on the processing, storage and transmission of sensitive information. • Main goal is to ensure information is appropriately protected from modification or disclosure. • May be appropriate to have new employees sign policy as part of their initial orientation. • Should define sensitivity levels of information.

  27. The Perimeter Security Policy • Describes, in general, how perimeter security is maintained. • Describes who is responsible for maintaining it. • Describes how hardware and software changes to perimeter security devices are managed and how changes are requested and approved.

  28. Virus Protection and Prevention Policy • Provides baseline requirements for the use of virus protection software. • Provides guidelines for reporting and containing virus infections. • Provides guidelines for several levels of virus risk. • Should discuss requirements for scanning email attachments. • Should discuss policy for the download and installation of public domain software.

  29. Virus Protection and Prevention Policy • Should discuss frequency of virus data file updates. • Should discuss testing procedures for installation of new software.

  30. Password Policy • Provides guidelines for how user level and system level passwords are managed and changed. • Discusses password construction rules. • Provides guidelines for how passwords are protected from disclosure. • Discusses application development guidelines for when passwords are needed. • Discusses the use of SNMP community strings and pass-phrases.

  31. Other Important Policies • A policy which addresses forwarding of email to offsite addresses. • A policy which addresses wireless networks. • A policy which addresses baseline lab security standards. • A policy which addresses baseline router configuration parameters. • A policy which addresses requirements for installing devices on a dirty network.

  32. Security Procedures • Policies only define "what" is to be protected. • Procedures define "how" to protect resources and are the mechanisms to enforce policy. • Procedures define detailed actions to take for specific incidents. • Procedures provide a quick reference in times of crisis. • 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).

  33. Configuration Management Procedure • Defines how new hardware/software is tested and installed. • Defines how hardware/software changes are documented. • Defines who must be informed when hardware and software changes occur. • Defines who has authority to make hardware and software configuration changes.

  34. Data Backup and Off-site Storage Procedures • Defines which file systems are backed up. • Defines how often backups are performed. • Defines how often storage media is rotated. • Defines how often backups are stored off-site. • Defines how storage media is labeled and documented.

  35. Incident Handling Procedure • Defines how to handle anomaly investigation and intruder attacks. • Defines areas of responsibilities for members of the response team. • Defines what information to record and track. • Defines who to notify and when. • Defines who can release information and the procedure for releasing the information. • Defines how a follow-up analysis should be performed and who will participate.

  36. RISK MANAGEMENT

  37. Risk Risk is the likelihood of the occurrence of a vulnerability multiplied by the value of the information asset minus the percentage of risk mitigated by current controls plus the uncertainty of current knowledge of the vulnerability

  38. What is Risk • A definable event • Probability of occurrence • Impact of occurrence • A risk occurs when the problem happens • Loss expectancy that a threat might exploit a vulnerability.

  39. Asset Relationship among different security components Gives rise to Threat Agent Exploits Threat Leads to Vulnerability Directly affects RISK Can damage Exposure Safeguard And causes an Can be counter measured by a

  40. 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? Impact What is the impact to the business? Probability How likely is the threat given the controls? Well-Formed Risk Statement Risk

  41. Vulnerability Identification • Vulnerability – is a software, hardware, or procedural weakness that may provide an attacker the open door to enter a system. • Specific avenues threat agents can exploit to attack an information asset are called vulnerabilities • Examine how each threat could be perpetrated and list organization’s assets and vulnerabilities • Process works best when people with diverse backgrounds within organization work iteratively in a series of brainstorming sessions • At the end of risk identification process, list of assets and their vulnerabilities is achieved

  42. Risk Mitigation • Understand security risk • Understand technology • Accept Risk • Documentation of risk acceptance is a form of mitigation. • Defer or transfer risk • Insurance • Mitigate risk • Technology can mitigate risk

  43. Risk Management Process

  44. How to Develop a Security Risk Management Process? • Security risk management process: • A process for identifying, prioritizing, and managing risk to an acceptable level within the organization • Developing a formal security risk management process must address the following: • Threat response time • Regulatory compliance • Infrastructure management costs • Risk identification and assessment (prioritization)

  45. Successful Factors for Security Risk Management Process Key factors to implementing a successful security risk management process include: • Executive sponsorship • Well-defined list of risk management stakeholders • Organizational maturity in terms of risk management • An atmosphere of open communications and teamwork • A holistic view of the organization • Security risk management team’s authority

  46. 1 Assessing Risk 4 Measuring Program Effectiveness 3 Implementing Controls 2 Conducting Decision Support Risk Management Process

  47. Input Risk Assessment Activities Output Risk Assessment Flowchart • Hardware / Software • System interfaces • Data and information • People • System mission • System Boundary • System Functions • System and DataCriticality • System and DataSensitivity Step 1.System Characterization • History of system attack • Data from intelligenceagencies, NIPC, OIG,FedCIRC, mass media, Step 2. Threat Identification Threat Statement • Reports from prior riskassessments • Any audit comments • Security requirements • Security test results Step 3. Vulnerability Identification List of PotentialVulnerabilities • Current controls • Planned controls Step 4. Control Analysis List of Current andPlanned Controls •Threat-source motivation • Threat capacity • Nature of vulnerability • Current controls Step 5. Likelihood Determination Likelihood Rating Step 6. Impact Analysis • Loss of Integrity • Loss of Availability • Loss of Confidentiality • Mission impact analysis • Asset criticality assessment • Data criticality • Data sensitivity Impact Rating • Likelihood of threatexploitation • Magnitude of impact • Adequacy of planned orcurrent controls Step 7. Risk Determination Risks and Associated RiskLevels Step 8.Control Recommendations RecommendedControls Step 9.Results Documentation Risk AssessmentReport

  48. Input Risk Mitigation Activities Output Risk Mitigation Flowchart • Risk levels from the risk assessment report Actions ranking from High to Low Step 1.Prioritize Actions Step 2.Evaluate Recommended Control Options • Associated costs • Feasibility • Risk assessmentreport List of possible controls Step 3.Conduct Cost-Benefit Analysis • Impact of implementing • Impact of not implementing • Associated costs Cost-benefitanalysis Selected Controls Step 4.Select Controls Step 5.Assign Responsibility List of responsible persons 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 Safeguardimplementation plan Step 7.Implement Selected Controls Residual Risks

  49. Risk Analysis Method

More Related