Information Systems Concerns and Risks

1
Information Systems Concerns and Risks
Raval Fichadia John Wiley Sons, Inc. 2007

• Chapter Two
• Prepared by Raval, Fichadia

2
(No Transcript)
3
Chapter Two Objectives

1. Understand what a target system is and appreciate
   its control and security concerns.
2. Explain the concepts of risk and risk exposure
   and how exposures are affected by changes in the
   firm.
3. Comprehend risk management in relation to
   business information systems.
4. Understand the building blocks of control and
   security solutions for information systems.
5. Infer the role of assurance in risk management of
   information systems.

4
Are you who the computer says you are?

• Computers surround us. They impact almost every
  facet of our lives.
• This causes the risk of too much information
  being out there.
• Frauds, such as identity theft, are therefore
  possible.
• Attempts to protect such data using technology
  are common and widely accepted.
• However, hackers evolve their strategies. This
  causes additional information systems concerns.

5
Control and Security of Target System

• Target system An information asset that should
  be protected from all types of risks.
• Examples The servers, operating system, e-mail
  application, customer database
• Target systems components
• An operating system
• A database management system
• Information processing systems
• End-user systems

6
Other Target System Characteristics

• Boundary
• Information systems boundaries have progressively
  become more porous, especially in the Web
  environment.
• Exposures from boundary arise due to
• Links (interfaces) with other systems
• Nature, type, and timing of traffic
• Availability of connectivity with the target
  system
• Communication
• Netcentric target systems have greater need for
  communication. Need more communication lines.
• Verfication (authentication) of communicators is
  critical.
• Objectives of boundary protection needs to be
  balanced with the objectives of controlled
  communication.

7
Other Target System Characteristics

• Location and spread
• Centralized systems are likely to have a
  well-defined perimeter.
• Physical security of a centralized system is
  feasible and is usually effective.
• Distributed systems are usually spread out,
  making boundaries much more porous.
• Outsourcing of information systems
• Some risks are shifted to the outsourcer.
• However, the company faces new risks.
• A careful risk-based evaluation of the
  outsourcing option is essential before the
  management commits to this option.

8
Risk

• Risk Risk represents the possibility of a loss
  or harm to an entity.
• An entity can be a person, an organization, a
  resource, a system, or a group.
• In our case, the entity can be broadly
  characterized as a target system (information
  assets).
• Risk exposures A risk exposure represents all
  kinds of possibilities of harm to an entity
  without regard to its likelihood.
• Not all exposures equally impact every entity.
• Therefore, risk is assessed in terms of those
  exposures that have a high probability of
  affecting the target system.
• Risks (and exposures) can be emerging from within
  (internal sources) or from outside the boundary
  of the organization (external).
• Risks keep changing. Existing risks may gain
  strength or weaken, and new risks emerge.

9
There are many factors causing changes in risk.

• Organizational factors
• Business firms constantly change their
  organizational structures to reflect changed
  responsibility relationship.
• Examples of change merger, acquisition,
  downsizing, seeking new markets or products.
• Environmental factors
• Businesses respond to changes in their
  environments.
• Examples of change regulation, international
  trade laws and treaties, economic cycles.
• Technological factors
• Changes in IT are likely to affect risks.
• Examples of change wireless networking, mobile
  computing, customers transacting online.
• Sociological factors
• Businesses are affected by sociological changes.
• Examples of change networking, telecommuting,
  remote logins, single parent homes, elderly care.

10
Risk Management

• Risk management A systematic approach to manage
  risk to a target system.
• Risk appetite An organizations ability to
  accept risk.
• Approaches to risk management
• Dont own (disown) the risk
• Risk avoidance A deliberate attempt to keep the
  target system away from a specific risk.
  Example Avoid travel by air.
• Own the risk
• Risk reduction Proactive measures to prevent a
  loss from occurring, or to limit losses.
  Example Firewall installation to screen traffic.
• Risk transfer Transfer target system risk to
  some other entity. Example outsourcing,
  subcontracting.
• Risk sharing Entities facing identical exposure
  join together and pool their resources. Example
  Neighborhood watch groups, insurance.
• Risk retention Managements desire to accept
  risk. Example Leadership tram traveling on the
  same flight.

11
(No Transcript)
12
Security, Functionality, and Usability of
Information Assets

• Security To protect systems and applications.
• Functionality To be effective in delivering the
  objectives for which systems and applications are
  designed.
• Usability To make systems and applications
  attractive (e.g., easy to use) to end users.
• Trade offs among the three goals are very likely
  and balance needs to be achieved among the three
  objectives.

13
Control Systems

• Control systems are integral to the process of
  risk management.
• Designing control systems are designed using
  components and constructs.
• Components are features integral to a control
  system.
• Logical constructs are rules of control systems
  design.
• Management of control systems (that concern
  information assets) should be assigned to a role
  that is responsible for information security.

14
Components of control systems

• Security policy and practices
• Identification and authentication
• Access and authorization
• Information flow
• Availability and continuity
• Logs and trails
• Risk-based audit

15
Security Policy and Practices

• A high-level document independent of all
  functions, roles, powers, and personalities with
  the firm.
• Provides consistency and balance in designing
  information security solutions.

16
Identification and Authentication

• Identification and authentication processes offer
  an assurance that we know the entities
  interacting with the system.
• Authentication procedures can be progressively
  more rigorous depending on the need
• First factor authentication what do you know?
  (e.g., password)
• Second factor authentication what do you have?
  (e.g., a token)
• Third factor authentication who are you? (e.g.,
  biometrics)

17
Access and Authorization

• Access means access to the system.
• Authorization defines what the user can do with
  the system.
• Authorization to use various information assets
  is dependent on the role of the user. User roles
  are inputs to determine user privileges with
  respect to the information assets (e.g., view or
  modify existing data in payroll database).

18
Information Flow

• Information flow has to do with pathways through
  which data travel across the network.
• Information flow needs to be identified both for
  the internal networks as well as for
  communication from outside the organization.

19
Availability and Continuity

• To ensure that information assets are available
  at the time of their expected use.
• Continuity of operations is dependent on
  availability of information assets.
• Lack of availability could be temporary or
  long-term.
• Lack availability can be caused by incidents or
  disasters.

20
Logs and Trails

• Logs reveal the sequence of events or activities
  taking place with respect to information
  processing.
• Date and time stamp provide evidence of sequence
  of actions with respect to the systems resources.
• Trails of transactions are generally formed as
  transaction logs. This allows for verification
  of transaction processing activities and for
  reconciliation of outputs of processing.

21
Risk-based Audit

• Audits are important to gain assurance that risks
  of information systems are well managed.
• Audits should be planned using the results of
  risk assessment.
• Information systems, by design, may include
  embedded audit modules (EAM) in the application
  code. An EAM monitors occurrences of exception
  conditions during transaction processing, and
  logs such transactions into an audit file for
  review by the auditor.

22
Logical Constructs of Control Systems

• Requisite variety
• Redundancy
• Granularity
• Encryption
• Protocols and standards
• RFCs
• Trust

23
Requisite Variety

• In any (information security) solution, the
  variety of responses included must be adequate to
  mitigate every possible out-of-control situation.
• Absence of requisite variety in a control systems
  could trigger, by default, incorrect or
  unintended responses.

24
Redundancy

• Many control and security measures employ
  redundancy to manage risk.
• Example Back up copy of a program.
• Redundancy creates inefficient utilization of
  resources.
• However, in certain cases, redundancy may provide
  a cost-effective control measure.

25
Granularity

• Granularity is the level at which a security or
  control measure is implemented within a hierarchy
  of levels in a system.
• Granularity is most visible in control and
  security measures with respect to access to
  information assets.
• For a chosen level of granularity, it is
  necessary to provide requisite variety for every
  possible out-of-control situation.

26
Encryption

• Encryption is the science of randomizing data to
  make them look like gibberish.
• Data garbled using encryption can be de-garbled
  using decryption.
• Encryption is feasible because of redundancy in a
  message.
• The process of encryption itself may use a method
  that is subject to redundancy.

27
Protocols and Standards

• Protocol means rules of behavior.
• Example Protocols are widely used in network
  communications field, including the Internet.
• The consistency provided by protocols allow
  users, designers, and evaluators of information
  systems the same expectations.
• An established protocol that becomes universally
  accepted over time is called a standard.

28
RFC

• Collectively, RFCs are a set of technical and
  organizational notes, predominantly about the
  Internet.
• Many of the standards that apply to information
  systems are recorded as RFC (initially designated
  as Request for Comments).
• Feedback from all interested parties (e.g.,
  researchers, vendors, users) is sought on an
  initial draft document.
• Following extensive analysis of feedback the
  document is refined and is eventually recognized
  as RFC (e.g., RFC 2555).

29
A summary of RFC 2196 RFC 2196 provides guidance
on the specifics that demand consideration in
implementing and revising a security plan. When
developing a security plan, one should identify
what assets are to be protected, what threats
should be protected against, and how likely the
threats are. These questions can be answered via
a detailed risk assessment. Assets to protect
include hardware, software, data, people,
documentation, and supplies. Likewise, classic
threats include unauthorized access, unwarranted
disclosure of information, and denial of
service. Then, it is important to Implement
measures which will protect your assets in a
cost-effective manner and review the process
continuously and make improvements each time a
weakness is found. Every enterprise should have
a security policy comprised of the specific rules
applicable to those given access to the
enterprises information and network sites. A
major component of the security policy is
definitions of classes of incidents and the
subsequent replies. RFC 2196 provides useful
guidance and examples on the causes and
characteristics of possible incidents and the
appropriate action to take while handling an
incident.
30
Selected RFCs
RFC Number Title Chapter in this book to which the RFC relates
3924 Cisco Architecture for Lawful Intercept in IP Networks 13
2196 Site Security Handbook 5
3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol 5, 13, 14
3852 Cryptographic Message Syntax 7
31
Trust

• Trust means relying on someone or something.
• When a level of trust is assumed, but is
  violated, security (of process, software, or
  system) is compromised.
• Therefore, it is important to evaluate the level
  of trust placed in people, processes, and
  systems.

32
Comparing Trust with Security

• Trustworthiness is a matter of degree, while
  security has two states (secured or not secured).
• Security is in the view of the presenter
  trusting is an act of the receiver.
• Security is argued on the basis of assertions of
  characteristics of the target system trust is a
  matter of judgment.
• A system is considered secure, regardless of how,
  when, where, by whom it is used. Trust is viewed
  only within the context of use it does not
  automatically transcent situations.

33
Common Criteria

• Common Criteria (CC) is a framework that helps
  develop and evaluate features that support
  information security objectives at various levels
  of assurance.
• It establishes a method for the evaluation of
  security properties of IT products and systems.
• Thus, it provides a standard for vendors of IT
  products and systems.
• Security managers acquiring IT products and
  systems carefully consider the level of assurance
  provided by alternative products in making their
  purchase decisions.

34
Implications for Assurance

• Target of evaluation (TOE) may be any object (a
  process, component, resource, or a system).
• The target is subject to a systematic evaluation
  to determine if it meets certain criteria.
• Steps in the evaluation process
• Understand the control environment.
• Determine what protections are planned and how
  security objectives are set to achieve these
  protections.
• Test the target to verify if the security
  objectives are met.
• Evaluate the evidence to make a final judgment on
  secure the TOE is.

35
(No Transcript)