Information Systems Concerns and Risks

1. Raval • Fichadia John Wiley & Sons, Inc. 2007 Information Systems Concerns and Risks Chapter Two Prepared by: Raval, Fichadia

3. Chapter Two Objectives • Understand what a target system is and appreciate its control and security concerns. • Explainthe concepts of risk and risk exposure and how exposures are affected by changes in the firm. • Comprehend risk management in relation to business information systems. • Understandthe building blocks of control and security solutions for information systems. • 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 system’s 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 organization’s ability to accept risk. • Approaches to risk management • Don’t 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: Management’s desire to accept risk. Example: Leadership tram traveling on the same flight.

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 enterprise’s 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

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.