Research report

gunnala

Ch10ManagementandIncidents.pptx

Home >Computer Science homework help >Research report

Security in Computing, Fifth Edition

Chapter 10: Management and Incidents

Chapter 10 Objectives

Study the contents of a good security plan

Learn to plan for business continuity and responding to incidents

Outline the steps and best practices of risk analysis

Learn to prepare for natural and human-caused disasters

Contents of a Security Plan

A security plan identifies and organizes the security activities for a computing system.

The plan is both a description of the current situation and a map for improvement.

The plan is both an official record of current security practices and a blueprint for orderly change to improve those practices.

Contents of a Security Plan

Policy, indicating the goals of a computer security effort and the willingness of the people involved to work to achieve those goals

Current state, describing the status of security at the time of the plan

Requirements, recommending ways to meet the security goals

Recommended controls, mapping controls to the vulnerabilities identified in the policy and requirements

Accountability, documenting who is responsible for each security activity

Timetable, identifying when different security functions are to be done

Maintenance, specifying a structure for periodically updating the security plan

Security Policy

A high-level statement of purpose and intent

Answers three essential questions:

Who should be allowed access?

To what system and organizational resources should access be allowed?

What types of access should each user be allowed for each resource?

Should specify

The organization’s security goals (e.g., define whether reliable service is a higher priority than preventing infiltration)

Where the responsibility for security lies (e.g., the security group or the user)

The organization’s commitment to security (e.g., defines where the security group fits in the corporate structure)

Security Policy

Security policies and plans can and often should exist at the level of systems or groups of systems.

An organization-wide security policy can address users and systems only in the context of fairly general roles, which, for many purposes, is not specific enough.

Whereas the organization as a whole may be primarily focused on maintaining confidentiality of data, certain systems in that organization may rightfully focus on maintaining availability as a top priority.

Assessment of Current Security Status

A risk analysis—a systemic investigation of the system, its environment, and what might go wrong—forms the basis for describing the current security state

Defines the limits of responsibility for security

Which assets are to be protected

Who is responsible for protecting them

Who is excluded from responsibility

Boundaries of responsibility

We look at risk analysis in more detail later in this chapter.

Security Requirements

Security requirements are functional or performance demands placed on a system to ensure a desired level of security

Usually derived from organizational business needs, sometimes including compliance with mandates imposed from outside, such as government standards

Characteristics of good security requirements:

Correctness

Consistency

Completeness

Realism

Need

Verifiability

Traceability

Security Requirements

Correctness: Are the requirements understandable? Are they stated without error?

Consistency: Are there any conflicting or ambiguous requirements?

Completeness: Are all possible situations addressed by the requirements?

Realism: Is it possible to implement what the requirements mandate?

Need: Are the requirements unnecessarily restrictive?

Verifiability: Can tests be written to demonstrate conclusively and objectively that the requirements have been met? Can the system or its functionality be measured in some way that will assess the degree to which the requirements are met?

Traceability: Can each requirement be traced to the functions and data related to it so that changes in a requirement can lead to easy reevaluation?

Responsibility for Implementation

A section of the security plan will identify which people (roles) are responsible for implementing security requirements

Common roles:

Users of personal computers or other devices may be responsible for the security of their own machines. Alternatively, the security plan may designate one person or group to be coordinator of personal computer security.

Project leaders may be responsible for the security of data and computations.

Managers may be responsible for seeing that the people they supervise implement security measures.

Database administrators may be responsible for the access to and integrity of data in their databases.

Information officers may be responsible for overseeing the creation and use of data; these officers may also be responsible for retention and proper disposal of data.

Personnel staff members may be responsible for security involving employees, for example, screening potential employees for trustworthiness and arranging security training programs.

Timetable and Plan Maintenance

As a security plan cannot be implemented instantly, the plan should include a timetable of how and when the elements in it will be performed

The plan should specify the order in which controls are to be implemented so that the most serious exposures are covered as soon as possible

The plan must be extensible, as new equipment will be acquired, new connectivity requested, and new threats identified

The plan must include procedures for change and growth

The plan must include a schedule for periodic review

Inputs to the Security Plan

This is a conceptual model of how the previous slides fit together.

Security Planning Team Members

Security planning touches every aspect of an organization and therefore requires participation well beyond the security group

Common security planning representation:

Computer hardware group

System administrators

Systems programmers

Applications programmers

Data entry personnel

Physical security personnel

Representative users

Assuring Commitment to a Security Plan

A plan that has no organizational* commitment collects dust on a shelf

Three groups of people must contribute to making the plan a success:

The planning team must be sensitive to the needs of each group affected by the plan.

Those affected by the security recommendations must understand what the plan means for the way they will use the system and perform their business activities. In particular, they must see how what they do can affect other users and other systems.

Management must be committed to using and enforcing the security aspects of the system.

Business Continuity Planning

A business continuity plan documents how a business will continue to function during or after a computer security incident

Addresses situations having two characteristics:

Catastrophic situations, in which all or a major part of a computing capability is suddenly unavailable

Long duration, in which the outage is expected to last for so long that business will suffer

The next slide addresses the specific tasks involved in business continuity planning.

Continuity Planning Activities

Assess the business impact of a crisis

What are the essential assets?

What could disrupt use of these assets?

Develop a strategy to control impact

Investigate how the key assets can be safeguarded

Develop and implement a plan for the strategy

Define:

Who is in charge when an incident occurs

What to do when an incident occurs

Who does what tasks when an incident occurs

Incident Response Plans

A security incident response plan tells the staff how to deal with a security incident

In contrast to a business continuity plan, the goal of incident response is handling the current security incident without direct regard for the business issues

An incident response plan should

Define what constitutes an incident

Identify who is responsible for taking charge of the situation

Describe the plan of action

Incident Response Teams

The response team is charged with responding to the incident. It may include

Director : The person in charge of the incident, who decides what actions to take

Technicians: People who perform the technical part of the response

Advisors: Legal, human resources, or public relations staff members as appropriate

Matters to consider when identifying a response team:

Legal issues

Preserving evidence

Records

Public relations

CSIRTs

Computer Security Incident Response Teams (CSIRT) are teams trained and authorized to handle security incidents

CSIRTs are closely related to Security Operations Centers (SOC), which perform day-to-day monitoring of a network and may be the first to detect an incident.

Responsibilities of a CSIRT include

Reporting: Receiving reports of suspected incidents and reporting as appropriate to senior management

Detection: Investigation to determine if an incident occurred

Triage: Immediate action to address urgent needs

Response: Coordination of effort to address all aspects in a manner appropriate to severity and time demands

Postmortem: Declaring the incident over and arranging to review the case to improve future response

Education: Preventing harm by advising on good security practices and disseminating lessons learned from past incidents

CSIRT Skills

Collect, analyze, and preserve digital forensic evidence

Analyze data to infer trends

Analyze the source, impact, and structure of malicious code

Help manage installations and networks by developing defenses such as signatures

Perform penetration testing and vulnerability analysis

Understand current technologies used in attacks

Risk Analysis

Risk analysis is an organized process for identifying the most significant risks in a computing environment, determining the impact of those risks, and weighing the desirability of applying various controls against those risks

A risk is a potential problem that the system or its users may experience – like the cost of a data breach*

Characteristics of a risk:

Associated loss (also known as a risk impact)

Likelihood of occurring

Degree to which we can change the outcome (risk control)

We can theoretically quantify the effects of a risk, or risk exposure, by multiplying likelihood by risk impact

Note that even though risks have likelihoods associated with them, those likelihoods, in the context of cybersecurity, are generally impossible to measure.

Strategies for Dealing with Risk

Avoid the risk by changing requirements for security or other system characteristics

Transfer the risk by allocating the risk to other systems, people, organizations, or assets or by buying insurance to cover any financial loss should the risk become a reality

Assume the risk by accepting it, controlling it with available resources, and preparing to deal with the loss if it occurs

Steps of a Risk Analysis

Identify assets.

Determine vulnerabilities.

Estimate likelihood of exploitation.

Compute expected annual loss.

Survey applicable controls and their costs.

Project annual savings of control.

These steps are discussed in more detail in the next slides.

Step 1: Identify Assets

Hardware: Processors, boards, keyboards, monitors, terminals, microcomputers, workstations, tape drives, printers, disks, disk drives, cables, connections, communications controllers, and communications media

Software: Source programs, object programs, purchased programs, in-house programs, utility programs, operating systems, systems programs (such as compilers), and maintenance diagnostic programs

Data: Data used during execution, stored data on various media, printed data, archival data, update logs, and audit records

People: Skilled staff needed to run the computing system or specific programs, as well as support personnel such as guards

Documentation: On programs, hardware, systems, administrative procedures, and the entire system

Supplies: Paper, forms, laser cartridges, recordable media, and printer ink, as well as power, heating and cooling, and necessary buildings or shelter

Reputation: Company image

Availability: Ability to do business, ability to resume business rapidly and efficiently after an incident

Step 2: Determine Vulnerabilities

This is an example of a matrix mapping vulnerabilities to assets. In real life, the matrix would be much longer and include much more specific assets. Numerous vulnerability types can apply broadly to a class of assets, however, so broad categories are useful and help identify organization-wide concerns.

In considering the contents of each matrix entry, we can ask some helpful questions:

What are the effects of unintentional errors? Consider typing the wrong command, entering the wrong data, using the wrong data item, discarding the wrong listing, and disposing of output insecurely.

What are the effects of willfully malicious insiders? Consider disgruntled employees, bribery, and curious browsers.

What are the effects of outsiders? Consider network access, remote access, hackers, people walking through the building, people snooping at coffee shops, and people sifting through the trash.

What are the effects of natural and physical disasters? Consider fires, storms, floods, power outages, and component failures.

Step 3: Estimate Likelihood of Exploitation

Because it is impossible to know all of a system’s vulnerabilities or all the ways those vulnerabilities can be exploited, is also impossible to accurately assess likelihood of exploitation

Possible approaches to estimation:

Apply frequency probability using observed data for a similar system

Use an analyst familiar with such systems to estimate number of occurrences in a given time period

Use descriptive adjectives or a simple rating system

The Delphi approach

The Delphi approach:

Provide each of several experts with information describing the situation surrounding the event under consideration. For example, the experts may be told about the software and hardware architecture, conditions of use, and expertise of users.

Each expert individually estimates the likelihood of the event. The estimates are collected, reproduced, and distributed to all experts.

The individual estimates are listed anonymously, and the experts are usually given some statistical information, such as mean or median.

The experts are then asked whether they wish to modify their individual estimates in light of values their colleagues have supplied.

If the revised values are reasonably consistent, the process ends with the group’s reaching consensus.

If the values are inconsistent, additional rounds of revision may occur until consensus is reached.

Quantitative vs. Qualitative Estimation

Step 4: Compute Expected Loss

In addition to the obvious costs, such as the cost to replace a hardware asset, there are hidden costs:

Cost of restoring the system to a previous state

Cost of downtime

Legal fees

Loss of reputation and confidence

Loss of confidentiality

Some hidden costs may be impossible to accurately evaluate, but considering them will nonetheless aid in risk management

Step 5: Survey and Select New Controls

Once you understand your assets, vulnerabilities, estimated likelihood of exploitation, and cost of exploitation, you have enough information to select controls

Each vulnerability may have one or more controls associated with it, and each control may work for many assets and multiple vulnerabilities

One approach is to use graph theory to select a minimal set of controls to address all vulnerabilities

Step 6: Project Costs and Savings

This step is meant to determine whether the costs of implementing controls outweigh the expected benefits

The effective cost of a given control is the actual cost of the control (including purchase price, installation and deployment costs, and training costs) minus the expected loss the control is expected to prevent

The cost may be positive if the product is very expensive or introduces new risks to the system, or it may be negative if the expected reduction in risk is greater than the cost of the control

Access Control Software Cost Example

Arguments for Risk Analysis

Improve awareness*

Relate security mission to management objectives

Identify assets, vulnerabilities, and controls

Improve basis for decisions

Justify expenditures for security

Improve awareness: Discussing issues of security can raise the general level of interest and concern among developers and users. Especially when the user population has little expertise in computing, the risk analysis can educate users about the role security plays in protecting functions and data that are essential to user operations and products.

Relate security mission to management objectives: Security is often perceived as a financial drain for no gain. Management does not always see that security helps balance harm and control costs.

Identify assets, vulnerabilities, and controls: Some organizations are unaware of their computing assets, their value to the organization, and the vulnerabilities associated with those assets. A systematic analysis produces a comprehensive list of assets, valuations, and risks.

Improve basis for decisions: A security manager can present an argument such as “I think we need a firewall here” or “I think we should use token-based authentication instead of passwords.” Risk analysis augments the manager’s judgment as a basis for the decision.

Justify expenditures for security: Some security mechanisms appear to be very expensive and without obvious benefit. A risk analysis can help identify instances where it is worth the expense to implement a major security mechanism. Managers can show the much larger risks of not spending for security.

Arguments Against Risk Analysis

False sense of precision and confidence

Hard to perform

Immutability

Lack of accuracy

False sense of precision and confidence: The heart of risk analysis is the use of empirical data to generate estimates of risk impact, risk probability, and risk exposure. The danger is that these numbers will give us a false sense of precision, thereby giving rise to an undeserved confidence in the numbers. However, in many cases the numbers themselves are much less important than their relative sizes. Whether an expected loss is $100,000 or $150,000 is relatively unimportant. It is much more significant that the expected loss is far above the $10,000 or $20,000 budget allocated for implementing a particular control. Moreover, anytime a risk analysis generates a large potential loss, the system deserves further scrutiny to see if the root cause of the risk can be addressed.

Hard to perform: Enumerating assets, vulnerabilities, and controls requires creative thinking. Assessing loss frequencies and impact can be difficult and subjective. A large risk analysis must consider many factors. Risk analysis can be restricted to certain assets or vulnerabilities, however.

Immutability: Many software project leaders view processes such as risk analysis as an irritating fact of life—a step to be taken in a hurry so that the developers can get on with the more interesting jobs related to designing, building, and testing the system. For this reason, risk analyses, like contingency plans and five-year plans, have a tendency to be filed and promptly forgotten. But if an organization takes security seriously, it will view the risk analysis as a living document, updating it at least annually or in conjunction with major system upgrades.

Lack of accuracy: Risk analysis is not always accurate, for many reasons. First, we may not be able to calculate the risk probability with any accuracy, especially when we have no past history of similar situations. Second, even if we know the likelihood, we cannot always estimate the risk impact very well. The risk management literature is replete with papers about describing the scenario, showing that presenting the same situation in two different ways to two equivalent groups of people can yield two radically different estimates of impact. And third, we may not be able to anticipate all the possible risks. For example, bridge builders did not know about the risks introduced by torque from high winds until the Tacoma Narrows Bridge twisted in the wind and collapsed. After studying the colossal failure of this bridge and discovering the cause, engineers made mandatory the inclusion of torque in their simulation parameters. Similarly, we may not know enough about software, security, or the context in which the system is to be used, so there may be gaps in our risk analysis that cause it to be inaccurate.

Natural Disasters

Examples:

Flood

Fire

Earthquake

Mitigations:

Develop contingency plans so that people know how to react in emergencies and business can continue

Insure physical assets—computers, buildings, devices, supplies—against harm

Preserve sensitive data by maintaining copies in physically separated locations

Prevent power loss using uninterruptable power supplies and surge suppressors

Interception of Sensitive Information

Mitigations:

Shred paper copies of sensitive information

Overwrite magnetic data several times using software designed for that purpose

Degauss magnetic media

Protect against RF emanation by trapping signals or adding spurious ones

Contingency Planning

Backups

Offsite backup

Cloud backup

Failover

Cold site

Hot site

Summary

A security plan is both an official record of current security practices and a blueprint for orderly change to improve those practices

Business contingency and incident response planning help establish an orderly, carefully considered response to emergencies and other security incidents

Risk analysis is a complex and imperfect process but forces an organization to carefully consider important assets, vulnerabilities, risks, and control options

Prepare for disasters by contingency planning, insuring assets, backing up data, and deploying failover sites

image2.emf

image3.png

image4.png

Pros

Cons

Quantitative

Chapter 1 Assessment and results based on independently objective processes and metrics. Meaningful statistical analysis is supported

Chapter 2 Value of information assets and expected loss expressed in monetary terms. Supporting rationale easily understood

Chapter 3 Provides credible basis for cost/benefit assessment of risk mitigation. Supports information security budget decision-making

Chapter 4 Calculations are complex. Management may mistrust the results of calculations and hence analysis

Chapter 5 Must gather substantial information about the target IT environment

Chapter 6 No standard independently developed and maintained threat population and frequency knowledge base. Users must rely on the credibility of the in-house or external threat likelihood assessment

Qualitative

Chapter 7 Simple calculations, readily understood and executed

Chapter 8 Not necessary to quantify threat frequency and impact data

Chapter 9 Not necessary to estimate cost of recommended risk mitigation measures and calculate cost/benefit

Chapter 10 A general indication of significant areas of risk that should be addressed is provided

Chapter 11 Results are subjective. Use of independently objective metrics is eschewed

Chapter 12 No effort to develop an objective monetary basis for the value of targeted information assets

Chapter 13 Provides no measurable basis for cost/benefit analysis of risk mitigation. Difficult to compare risk to control cost

Chapter 14 Not possible to track risk management performance objectively when all measures are subjective

Research report

image2.emf

image3.png

image4.png

image5.png