Chapter 6: IT Security and Risk Management Flashcards Preview

Informations und Wissensmanagement > Chapter 6: IT Security and Risk Management > Flashcards

Flashcards in Chapter 6: IT Security and Risk Management Deck (24):
1

Foundations 

  • Security is the absence of unbearable risks (DIN 2002)

  • Risk is the probability of an adverse future event mulitplied by its magnitude

  • Risk is the probability that a particular adverse event occurs during a stated period of time, or results from a particular challenge. The Royal Society (1992) 

2

Why IT Security? NI

„Worldwide around 40% of organizations complain about immaterial damages such as loss of reputation, sinking employee motivation or an adverse effect on business relations. After corruption incidences, more than two thirds of German organizations (68%) suffered these kinds of consequential damage.“ 

Negative impact of incidents:

  • Loss of reputation for company/brand (68%)
  • Impairment of business connections (52%)
  • Decline in employee moral/motivation (28%) 

3

IT Security Properties 

  • Confidentiality

    • Information about system or its users cannot be learned by an attacker

  • Integrity

    • The system continues to operate properly, only reaching states that would occur if there were no attacker

  • Availability

    • Actions by an attacker do not prevent users from having access to use of the system 

4

Management of Information Security 

5

IT security objectives 

6

Methods to achieve Basic Security Service Objectives 

  • Confidentiality

    • Encryption (symmetric vs. asymmetric)

  • Integrity

    • Hash-Functions

  • Authentication

    • Knowledge of a secret (e.g.: password)

    • Possession of a certain object (e.g.: chip card)

    • Human characteristics (e.g.: finger print)

  • Availability

    • Redundancy 

7

Benefit-cost-relation for IT security 

Pareto - becomes imense expensive

8

Example Threat-Matrix 

9

Example Threat Tree: Stealing Customer Data of ABC Corp. 

10

Defensive Measures 

  • Security Policies

    • What kind of passwords are users allowed to create for use on company systems? How often should they change password?

    • Who is allowed to have accounts on company systems?

    • What security features must be activated on a computer before it can connect to a company network?

    • What services are allowed to operate inside a company’s network?

    • What are users allowed to download?

    • How is the security policy enforced?

  • Further,

    Security policy must be accessible to all employees It must be reasonable from the users’ standpoint

  • Firewalls

    • Prevent unauthorized access to a company’s internal resources

    • Located typically at the point of connection between the internal network and the external public network 

  • Encryption

    • Can provide a high degree of protection against a vast majority of potential attackers

    • Transmission contents are decrypted by using a “key” 

  • Patching and Change Management

    • Attacks often exploit weaknesses for which patches would already be available

    • Timely application of fixes to existing systems

  • Intrusion detection and network monitoring

    • Helps recognize attacks (when it is taking place or when it has already taken place)  

       

11

Security Management Guidelines 

  • Make deliberate security decisions
  • Consider security as a moving target
  • Practice disciplined change management
  • Educate users
  • Deploy multi-level technical measures, as many as you can afford 

12

The Issue of Risk 

  • Risk is neither good or bad – it is just a fact
  • Some projects involve more risks than others
  • Organizations should be prepared to invest in high risk projects only when the return is high BUT don’t place all your assets in high risk projects 

The Question:

  • How can one determine a high-risk and a low-risk IT project in the absence of “trusted IT advisors”? 

13

Risk Categorization!!!

  • Known risks

    • Those risks that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date)

  • Predictable risks

    • Those risks that are extrapolated from past project experience (e.g., past turnover)

  • Unpredictable risks

    • Those risks that can and do occur, but are extremely difficult to identify in advance (e.g., zero-day attack) 

14

The Issue of Project Risks 

  • Project characteristics
  • Applegate, McFarlan and McKenney (1999) refer to three project dimensions which have the primary influence on implementation risk
    • project size,
    • the degree of new technology involved, and
    • the level of problem structure in the project. 

15

Project Characteristics 

  • Size of project — in terms of workers/years of effort

    • This is a simple but important risk dimension measurable in worker/years.

    • The interpersonal communications task alone increases exponentially with the size of the team. 

  • Degree of company-relative technology experience 

    • There is an education/familiarization cost associated with new or untried:

      • tools

      • concepts

      • hardware features

      • suppliers of hardware or software

      • communications standards

  • Degree of inherent structure

    • How well-defined are the project’s outputs?

    • How well does the implementation team understand what has been requested?

    • Have they built a system like this before (plan to throw one away...) 

       

16

Understanding the Degree of IT Project Risk 

17

Degree of IT Project Risk !!!

  • High project structure — low technology shift (Relatively Risk Free)
    • can be managed with good planning
    • will only become risky if size of the project begins to exceed familiar levels
  • High project structure — high technology shift. (Medium Level of Risk )

    • Risk is associated with uncertainty about the new technology

    • Formal planning can help but can be limited because of unknown factors surrounding the technology 

  • Low project structure— low technology shift (Low Level of Risk)

    • Risk is associated with the lack of structure in the problem

    • Communication is important. Formal planning and control mechanisms are valuable, with flexibility to adjust to new insights as the problem structure is clarified

    • As size increases so does the project risk 

  • Low project structure— high technology shift (High Level of Risk)

    • Regardless of the project management methodology, and often in spite of the management effort, these can still fail

    • Communication is critical. Formal planning and control mechanisms are valuable, but the lack of problem structure and unexpected technology problems can kill you!!! 

18

Reactive vs. Proactive Risk Strategies 

  • Reactive risk strategies
    • "Don't worry, I'll think of something"
    • The majority of software teams and managers rely on this approach
    • Nothing is done about risks until something goes wrong
      • The team then flies into action in an attempt to correct the problem rapidly (fire fighting)
    • Crisis management is the choice of management techniques
  • Proactive risk strategies
    • Steps for risk management are followed
    • Primary objective is to avoid risk and to have a contingency plan in place to handle unavoidable risks in a controlled and effective manner 

19

Value-Oriented Risk Management Approach

20

IT Risks and Effects 

21

IT risk management model 

22

Risk Management Process within IM 

23

Risk-Portfolio and To-Be Risk Level 

24

Summary