Risk Response Tutorial

3.1 Risk Response

Hello! Welcome to the domain Risk Response of Certified in Risk and Information Systems Control (CRISC) Course offered by Simplilearn. This lesson covers information technology risk response and mitigation. The focus of this lesson is that the CRISC candidate should determine risk response options and evaluate their efficiency and effectiveness to manage risk in alignment with business objectives. Let us look at the objectives of this lesson in the next screen.

3.2 Objectives

After completing this lesson, you will be able to: List the different risk response options and define various parameters for risk response selection Explain how residual risk relates to inherent risk, risk appetite, and risk tolerance Discuss the need for performing a cost-benefit analysis when determining a risk response and develop a risk action plan Explain the principles of risk ownership Leverage understanding of the system development life cycle or SDLC process to implement Information Systems or IS controls efficiently and effectively Understand the need for control maintenance We shall look at task statements of this lesson in the next screen.

3.3 Task Statements

CRISC professionals are required to perform various tasks, such as risk identification, assessment, evaluation, monitoring, and so on as part of their regular responsibilities. Analysis of the job practice of these security professionals led to defining and elaborating on the task and knowledge statements. Task statements basically list down the tasks that an information security professional must do. Okay, now let’s begin with learning about task statements. The seven task statements prescribed by ISACA® are: Select and align recommended risk responses with business objectives and enable informed risk decision in consultation with risk owners Develop risk action plans to ensure that plans include key elements in consultation risk owners Consult on the design and implementation of mitigating controls to manage risk to an acceptable level Ensure that control ownership is assigned in order to establish clear lines of accountability Assist control owners in developing control procedures and documentation to enable efficient and effective control execution Update the risk register to reflect changes in risk and management’s risk response Validate risk responses that have been executed according to the risk action plans Let us look at the CRISC knowledge statements on risk response in the next screen.

3.4 Knowledge Statements

Well, now that you know what task statements are, let’s learn about knowledge statements. Knowledge statements are those aspects of information security that an information security professional must have a thorough knowledge of. These statements help the security professional to perform the tasks required. The CRISC® candidate should have knowledge of: Business objectives and goals Industry trends and emerging technologies Laws, regulations, standards, and compliance requirements Contractual requirements with third-party service providers and customers and Enterprise systems architecture (for example, platforms, networks, applications, databases, and operating systems) Let us attempt a quick recall question in the next screen.

3.5 Knowledge Check

This question will help you recall the concepts you learned.

3.6 Overview

Now that you have learned about knowledge statements, let’s learn about the role of risk management. The role of risk management include: Risk identification Risk assessment Risk response and mitigation Risk and control monitoring and reporting Click each tab to know more about the role of risk management. Risk identification: The risk response phase of risk management shown requires the management to make the decisions regarding the correct way to respond to and address risk. Risk assessment: The risk response decision is based on the information provided in the earlier steps of risk identification and risk assessment, but is balanced with the constraints placed on the organization through budget, time, resources, strategic plans, regulations and customer expectations. Risk response and mitigation: Management must be prepared to justify its risk response decision and provide a road map to implement the changes that have been decided according to a reasonable schedule and Risk and control monitoring and reporting: The risk response must ensure that business operations are protected by controls that are put in place to address risk without unduly impairing or impacting the operations. We shall learn about the commonly used options for risk response in the next screen.

3.7 Risk Response Options

Risk management process involves activities that include identifying, analyzing, prioritizing and responding to risks.  Risk response is defined so as to align risk with the defined organization’s risk appetite. There are some commonly used options for risk response. They are: • Risk acceptance • Risk mitigation • Risk avoidance and • Risk transfer Let us learn about the first option for risk response namely, risk acceptance in the next screen.

3.8 Response Risk Options: Risk Acceptance

Risk acceptance is a good and necessary risk response technique of risk management. It is a decision made by senior management to recognize the existence of risk and knowingly decides to allow the risk to remain without mitigation and is the amount of risk that senior management has determined to be within acceptable levels. It involves the following criteria, namely risk ignorance, risk tolerance, and self-insurance. Click each tab to know more. Risk ignorance is the decision to blindly accept risk without acknowledging the risk level and Risk tolerance is the decision to accept the risk even if the level of risk exceeds the risk acceptance level set by senior management. Self-insurance: Self-insurance is a form of risk acceptance that manages only magnitude of the loss and has no impact on frequency. Let us continue to look at some examples of risk acceptance in the next screen.

3.9 Risk Response Options: Risk Acceptance (contd.)

Alright, you learned the different criteria of risk acceptance. Let’s learn some examples of risk acceptance. They are: A particular risk is assessed to be extremely rare but very important or catastrophic, and approaches to reduce it are prohibitive. Management may decide to accept this risk. It is predicted that a certain project will not deliver the required business functionality by the planned delivery date. The management may decide to accept the risk and proceed with the project. We will discuss about the second option of risk response namely, risk mitigation in the next screen.

3.10 Risk Response Options: Risk Mitigation

In addition to understanding risk acceptance, you should also know what risk mitigation refers to. Risk mitigation refers to actions taken to reduce the impact and frequency of a risk. Risk mitigation examples include: Deploying new technical and operational controls to reduce impact and likelihood of adverse event. Strengthening overall risk management practices, such as implementing sufficiently mature risk management processes Using compensating controls Installing a new access control system Implementing policies and operational procedures Developing an effective incident response and business continuity plan (BCP) We shall discuss about the third option of risk response namely, risk avoidance in the next screen.

3.11 Risk Response Options: Risk Avoidance

The next risk response option is risk avoidance. By all means, risk avoidance is the removal of risks that are likely to cause threat to an organization's assets. It also means exiting the activities or conditions that give rise to risk. Risk avoidance is adequate when: The risk cannot be shared or transferred The exposure level is deemed unacceptable by management There is no other cost-effective response that can succeed in reducing the frequency and impact below the defined thresholds for risk appetite Let us now look at some examples of risk avoidance in the next screen.

3.12 Risk Response Options: Risk Avoidance (contd.)

Well, here are some examples of risk avoidance in IT. They are: Declining to engage in a very large project when the business case shows a notable risk of failure Relocating a data center away from a region with significant natural hazards Avoiding certain technologies or software package because it would prevent future expansion and Declining to engage in a project that would build on obsolete and convoluted systems because there is no acceptable degree of confidence that the project will deliver anything workable And finally, we shall learn about the last risk response option namely, risk sharing in the next screen.

3.13 Risk Response Options: Risk Sharing

The last option of risk response is risk sharing. Risk sharing refers to the decision to reduce loss through sharing the risk of loss with another organization and is often done through purchasing insurance. Say for instance, an organization that purchases insurance to cover for fire damage and pay an annual insurance premium. The decision to transfer risk must be reviewed on a regular basis. For example, an organization should ensure that the current amount of insurance is adequate to cover losses and that the organization is compliant with the terms and conditions of the coverage. Let us look at the factors used to select a response and the cost of the various response options in the next screen.

3.14 Knowledge Check

This question will help you recall the concepts you learned.

3.15 Response Analysis

After learning about risk sharing, let’s now learn about the factors that are considered by management in selecting a response. The risk response chosen by the management is often based on the evaluation of response options. Several factors considered by management in selecting a response include: The recommended controls from the risk assessment report The priority level of the risk as indicated by the risk assessment report and Any other suggested response alternatives from further analysis The cost of the various response options are: Impact of productivity Acquisition cost Training cost and Maintenance and licensing costs In the next screen, we shall continue to learn more about response analysis.

3.16 Response Analysis (contd.)

Okay, now let’s learn about other factors considered by management of the organization in selecting a response. They are: Compatibility with other controls in place Alignment of the response option with the organizational strategy Possibility of integrating the response with other initiatives of the organization Time, budget, and resources available and Legislations and regulations compliance requirements Let us learn about cost-benefit analysis as part of response analysis in the next screen.

3.18 Response Analysis: Return on Investment

Return on investment or ROI is the profit earned by an investor as a result of some investment. A high ROI means the investment gains are higher than the investment cost. It is used as a method to justify an investment in a project, tool or new venture. According to ROI calculations: An investment would be expected to pay for itself within a set time period. The organization tries to forecast the likelihood and impact of an incident and decide on the adequate level of protection in determining ROI. The ROI based on the implementation of a control is often difficult to determine. It is hard to predict the likelihood of a successful attack since the cost of the control and the ROI of the control may need to be spread over several years. Let us learn about return on security investment in the next screen.

3.19 Response Analysis: Return on Investment (contd.)

In addition to ROI, now let’s understand what return on security investment (ROSI) is? The term ROSI is: Used by some organizations to refer to ROI in relation to payback for security controls Impossible to forecast what the true benefit of a security control would have been depending on if an adverse event occurred The cost of control may or may not provide a direct benefit in the future just like the purchase of insurance and The amount of security an organization decides to implement is dependent on their risk appetite and perception of the probability of exposure In the next screen, let us learn about developing risk response plans.

3.20 Risk Response: Plans Developing a Risk Response Plan

The process of risk response planning involves activities that include developing options, determining actions to increase opportunities and decrease the level of threats, and identifying and assigning individuals to take the responsibility for each risk response. The risk practitioner consults with risk owners when deciding on the correct response to a risk (whether to accept, avoid, transfer, or mitigate a risk). The risk practitioner can provide advice on: Technologies Policies Procedures Control effectiveness and Leveraging of existing controls even though the ultimate decision on risk response is the responsibility of the risk owner We shall now learn about the factors that are used for developing risk response plan in the next screen.

3.21 Risk Response: Plans Developing a Risk Response Plan (contd.)

As you have learned the different areas where the risk practitioner provides advice on, let’s see the factors that are used for developing risk response plan. The decision plan to implement a control is often based on factors such as: Budget Current risk level Regulations Ongoing projects Strategic plans Availability of staff Actions of competitors Public pressure In the next screen, we shall learn about the concepts involved in developing risk response process.

3.22 Risk Response: Plans Developing a Risk Response Plan (contd.)

Well, now that you know the factors that are used for developing risk response plan, let’s learn about the concepts of the risk response process. The risk response process involves the some concepts. They are: Risk scenarios Risk analysis Risk response Risk response options Selected risk response Prioritized risk responses Click each tab to know more about the risk response process. Risk scenarios (from risk identification) drive the risk analysis and assessment. Risk analysis (from risk assessment) leads to the documentation (mapping) of risk. Risk response is determined by the risk appetite of the organization. If the risk exceeds the appetite, then a risk response to address the risk must be considered. The risk response options are considered along with the risk response parameters to determine the best available risk response. The selected risk response is documented. The risk responses are prioritized according to the current risk environment and the cost-benefit of risk mitigation. A risk action plan is created to manage the risk response projects. Let us attempt a quick recall question in the next screen.

3.23 Knowledge Check

This question will help you recall the concepts you learned.

3.24 Risk Response: Plans Developing a Risk Response Plan (contd.)

Alright, you will now learn about risk parameters that influence risk response. The risk response may also be influenced by several risk parameters such as: The decision to implement a certain control and The several controls available and the organization The choice of controls to implement includes reviewing the efficiency of the proposed control in terms of: Would it be effective? Would it provide a satisfactory ROI? Does the organization have sufficient skill to implement, configure and maintain the control? Is there sufficient budget and time to implement the control? How much would it cost to operate on an annual basis and its impact on productivity? Let us learn about the components that must be included in developing risk action plan in the next screen.

3.25 Risk Response: Plans Developing a Risk Response Plan (contd.)

A risk action plan is the course of action that helps an organization to identify potential risks and tackle them. The risk action plan must include: Project start date Project end date Change in the delivery of any project Feasibility of project dates Click each tab to know more. Project start date: The risk action plan should be run as a project with a defined start and end date. Project end date: The end date is often used to determine the critical path or the elements of the project that may have a direct impact on whether the project can meet the end date. A change in the delivery of any project element that is on the critical path affects the delivery of the entire project Feasibility of project dates: The risk practitioner, through experience and careful evaluation, should advise the risk owner on the feasibility of project dates, the expected workload associated with the project, the costs of the project and the overall success of the project according to risk management and business goals. Let us learn about control objectives and practices in the next screen.

3.26 Control Objectives and Practices

Now that you have learned about risk action plan, let’s move on to control objectives and practices. In the previous domain, you have learned that COBIT is a framework of the best practices for IT management. The risk response phase of risk management: Chooses controls to address Ensures IT risk are within acceptable risk levels Requires the measurement and monitoring of risk Supports the next phase, risk and control monitoring and reporting, by putting into place the mechanisms and ability to measure risk and monitor the effectiveness of the controls and Compares to industry standards, benchmarks and recognized good practices We shall look at the business processes with reference to control objectives and practices in the next screen.

3.27 Control Objectives and Practices: Business Processes

Let’s learn how business processes function with reference to control objectives and practices. Risk management and implementation of controls should: Not affect business operation, or either of its objective but rather the risk response should ensure compliance with standards of risk management Business process that involve sensitive information, must be designed to protect the information from unauthorized disclosure, alteration or deletion (such as personal health information ) The risk response should ensure compliance with standards of risk management such as local regulation, international standards (for example, ISO 27001), industry standards and internal standards (for example, organizational culture, policy, and procedures) and The results of the risk response may lead to accreditation of the organization as compliant with an international standard such as ISO/IEC 27001 Let us look at information security with reference to control objectives and practices in the next screen.

3.28 Control Objectives and Practices: Information Security

What are the information security aspects that risk response should ensure? Risk response should ensure that: Technology used in the organization is adequately protected, secure, and reliable Proactive risk assessment and mitigation program to evaluate the risk associated with new technology and advice on deployment and use of the new technology within acceptable risk boundaries Deployment of new technology includes: Training for users and administrators Creating of policies and procedures Including such systems in backups and BCPs Assigning ownership for the risk Consenting information owners for technology that may handle sensitive information Assigning responsibility for monitoring and reporting on the proper use of such technology and Reviewing legal or regulatory requirements Let us learn more about information security with reference to control objectives and practices in the next screen.

3.29 Control Objectives and Practices:Information Security (contd.)

After learning about deployment of new technology, you will learn about the control objectives information security aspects. The control objectives of information security include: Change control Certification and accreditation (C&A) Asset inventory and documentation Configuration management Click each tab to know more about the control objectives of information security. Change control is often managed through a change control board (CCB) or other such committee. A CCB is comprised of representatives from several business departments and is responsible for overseeing all information systems operations and approving changes to those systems. This provides a communications channel between the business units and the IT department. The CCB reviews the change requests as they are released from vendors to ensure that: The change is scheduled at a convenient time for both business and IT The change request does not unknowingly affect the security The change is formally requested, approved and documented and All stakeholders affected by the change are advised of the change Certification and accreditation (C&A) is the process of objective management and acceptance of risk associated with the installation and operation of information systems. The purpose of C&A is to provide an organization wide approach to the management of IT risk by ensuring that all information systems are subject to review and approved for operation. Certification is the process of: Reviewing information systems with regard to their secure design, development, testing, deployment, and operations Certification should be done in parallel with the system development life cycle (SDLC) to ensure that any unacceptable risk is identified promptly and addressed to system and project management and Accreditation is the official, formal decision by a senior manager to authorize an information system to operate Asset Inventory and Documentation is the identification and inventory of the assets, is an important part of managing risk of the organization. The asset inventory must be updated to: Reflect what assets, systems, and equipment the organization is currently using Update inventory when changes are made to systems, older equipment retired, or new equipment installed List inventory of all equipment, owner, the location of the equipment, and other data required for maintenance, warranty, and insurance purposes Configuration Management: The devices and systems must be: Configured to support communications, interfaces with other systems and secure operations This often requires the hardening of systems to disable ports, services, and protocols that are not required to be operational on the system Hardening a system or device reduces the attack vectors or attack surface that could be used as a potential point of compromise A hardened system has all unnecessary functionality disabled and does not store any sensitive data that are not immediately required by a business operation. For example, a web server should be installed onto a secure host that has very little functionality and should never contain credit card data or other sensitive information. A common error is storing such sensitive information on the web server for convenience, only to have these data stolen by an attacker who compromised the web application and The rules (for example, configuration) that control the operation of devices, such as a firewall, must also be backed up and available in case of equipment failure. By having a backup of the configuration, the ability to recover the system is facilitated and often much faster Let us attempt a quick recall question in the next screen.

3.30 Knowledge Check

This question will help you recall the concepts you learned.

3.31 Control Objectives and Practices: Third-party Management

After understanding the control objectives of information security, let’s learn about the role of third-party management with reference to control objectives and practices. When the management of data is outsourced, the outsourcing organization must ensure that: The security requirements and regulations for handling the information have been written into the outsourcing agreement and are being followed The risks that arise when an organization outsources business functions, IT services, and data management should be addressed by the risk practitioner The ownership of business processes and the data remains with the organization that is doing the outsourcing and When an organization is contracted to deliver services or equipment, the risk of noncompliance with the agreement must be met through review, monitoring, and enforcement of the contract terms We shall concerns that should be addressed in relation to the risk of using third-party management in the next screen.

3.32 Control Objectives and Practices: Third-party Management (contd.)

Well, the concerns that should be addressed in relation to the risk of using a third-party include: Length of contract and terms for termination Reporting and liaison between the outsourcing organization and supplier Time to respond to any incidents Nondisclosure of business practices and data Responding to requests from law enforcement Location of data storage including backup data Liability for noncompliance with terms of the contract Separation between data and management of data of competing firms and Hiring and training practices of the supplier Let us learn about control objectives and practices for data management in the next screen.

3.33 Control Objectives and Practices: Data Management

Do you know why data must be protected? Data must be protected to ensure that no information is lost or accessed in an unauthorized manner. It also includes: Protection of data begins as soon as the data is received and is subject to validation. This may be done through a whitelist (a list of what data are allowed) or a blacklist (a list of what data are not allowed) Processing data are further protected by ensuring that changes cannot be made that would affect the integrity, precision or accuracy of the data, and data processing operations and Protecting data in storage includes actions such as isolation and the use of encryption which can be accomplished through network segmentation (including the use of firewalls and virtual local area networks or [VLANs]), role-based access control, physical access controls, and data encryption You will learn about objectives and practices for data management in the next screen.

3.34 Control Objectives and Practices: Data Management (contd.)

Processing data protection starts as soon as data is received. Input data should be subject to validation checks before acceptance or processing. Validation of input data includes: Format checks (for example, configuration of date) Range checks (for example, allowable data values) Allowable values (for example, months of the year) Special character checks (for example, prevent script commands) and Size (for example, prevent buffer overflows [too much data] or incomplete data [too little data]) Let us learn more about control objectives and practices in terms of cryptography in the next screen.

3.35 Control Objectives and Practices: Data Management-Cryptography

Now that you have learned about data management, let us understand how cryptography helps in data management. Encryption is used to protect the confidentiality of data by making data unreadable to unauthorized personnel, or protecting the integrity through hashing and digital signature. Its benefits include: Confidentiality Integrity Authentication Non-repudiation (proof of origin) and Access control Let us learn more about control objectives and practices for information systems architecture in the next screen.

3.36 Knowledge Check

This question will help you recall the concepts you learned.

3.37 Control Objectives and Practices: Information Systems Architecture

Let’s now move on to the components of information systems architecture. Each of the components of an information system requires: Different risk response options that will best mitigate the risk in the device or layer and Each device is best protected by using the risk mitigation option that is best suited for that device. For example, risk associated with a network layer attack are best mitigated using risk response solutions best suited for network-based attacks In the next screen, we shall learn about platforms and operating systems in information security architecture.

3.38 Control Objectives and Practices: Information Systems Architecture (contd.)

Let’s now look at the information systems architecture. In an information systems architecture: The risk practitioner should be aware of the risk of purchasing infected equipment and use trusted vendors The IT team must ensure that the maintenance hooks that vendors can use to gain access to the system have been secured and all vendor-supplied default accounts and passwords are changed Strict controls over changes, patches, and configurations should be implemented, while the systems should be hardened to disable all unnecessary services, and default accounts and passwords must be changed Securing platforms requires a patch management process that identifies, tests, and schedules the implementation of the patches and then monitors systems to ensure that they are still working correctly and lastly Another important consideration is the culture of the IT operations team. If the IT team is overconfident, they may not be careful enough to protect their systems and might leave them vulnerable. Say for instance, if the UNIX support team in an organization is overconfident and does not put adequate controls into place, an attacker may be able to circumvent these weak controls and breach the security of this system Let us attempt a quick recall question in the next screen.

3.40 Control Objectives and Practices: Information Systems Architecture (contd.)

Flaws or bugs in the coding of the application often result in application risk. Proper design, coding, and testing are some of the countermeasures to web application vulnerabilities. Applications should be designed to protect information using mechanism such as: Menus to restrict actions that are available to the user Masking to hide sensitive data Drop-down boxes to limit input options Range checks to ensure expected or correct data values are submitted Logs to record all activity and Balancing to ensure proper processing of transactions We shall learn about how applications should be designed in information security architecture in the next screen.

3.41 Control Objectives and Practices: Information Systems Architecture (contd.)

Do you know how applications are designed in information security architecture? Applications should be designed to protect information using mechanism such as: Access controls to restrict user access Certificates to authenticate entities Encryption to transmit sensitive data Documentation to facilitate maintenance Coding standards to support best practice in coding Legacy applications may need to be protected through the use of middleware to isolate direct access and manage data input or output, network isolation, and secure communications channels because of other vulnerabilities due to older standards in coding or design Errors should be coded and provide as little information as possible to the user. The process of error handling is a common problem with applications. If error messages are too verbose, they might provide information to an attacker that can be used to modify the attack and lastly The use of two-factor authentication especially for critical systems, is usually desirable, and after a few invalid login attempts, the user should be denied entry Let us learn about databases in information security architecture in the next screen.

3.42 Control Objectives and Practices: Information Systems Architecture (contd.)

As you know, databases contain critical and sensitive information that is required to support business operations and therefore it should be secured through: Content-based access controls that restrict access to sensitive records Restricting administrator-level access Encryption of sensitive data in the database Secure protocols to communicate with the database Use of database views to restrict information available to a user Efficient indexing to enhance data retrieval In the next screen, we shall learn how to secure databases in information security architecture.

3.43 Control Objectives and Practices: Information Systems Architecture (contd.)

After learning about databases in information security architecture, let’s learn how databases can be secured. Databases can also be secured through: Defined data fields (schema) Lockups of databases (shadowing, mirroring) Referential integrity Entity integrity Input Validation and Backups of transaction journals (remote journaling) In the next screen, we shall learn about networks in information security architecture.

3.44 Control Objectives and Practices: Information Systems Architecture (contd.)

Okay, now let’s learn about the role of network security in information security architecture? Network security protects: The confidentiality of data to ensure that confidential data were not disclosed to unauthorized parties during transmission The integrity of data being transmitted to ensure that the data received are the same as the data sent and Availability to ensure that network communications were available for use whenever required by the organization In the next screen, we shall learn more about networks in information security architecture.

3.45 Control Objectives and Practices: Information Systems Architecture (contd.)

The integrity of network communications is enabled through parity bits, checksums, hashing and digital signatures. Confidentiality of network data is accomplished through encryption which is provided through the use of encapsulating security payload (ESP) mode of lPsec Network availability is provided through alternate routing, redundancy of cable and network devices, and load balancing and The architecture of the network is important to isolate network segments and limit access to areas of the network and devices attached to the network and this is important when the network is used for devices such as point-of-sale terminals or other systems that handle sensitive data. Such devices should operate on a separate network segment to reduce the risk of data capture or modification In the next screen, we shall learn why network segmentation is often provided in information security architecture.

3.46 Control Objectives and Practices: Information Systems Architecture (contd.)

Alright, let’s now learn why network security is needed? Network segmentation is often provided through the use of firewalls and gateways to control the flow of traffic between network segments. A layered defense can also be used by networks to provide adequate protection by using several devices to provide a series of hurdles that an attacker would have to overcome to successfully exploit the network. Devices used for layered defense include intrusion detection and intrusion prevention systems (IDSs/IPSs), VLANs and bastion hosts. The Internet is not secure, and any data sent over the Internet are subject to compromise unless they are protected using a virtual private network (VPN) or other solution and A demilitarized zone (DMZ) should be designed to only provide the minimal levels of access required though not fully secure in order for an organization to provide access to customers and services. In the next screen, we shall learn how a network in information security architecture works.

3.47 Control Objectives and Practices: Information Systems Architecture (contd.)

Let’s now understand further the working of a network in information security architecture. An extranet is a private network that resides on the Internet and allows a company to securely share business information with customers, suppliers or other businesses as well as to execute electronic transactions. This can be a secured closed network from a network provider, or a virtual network using the Internet, secured with certificates, two-factor authentication, or other methods. In the absence of proper protection, the network devices are vulnerable to risk that can cause severe lapses in business continuity. Appropriate network security architecture should apply the following guidelines. They are: Administration of network devices should only be performed by authorized personnel and only through a change control and quality assurance process. Small error by network administrators can lead to serious consequences When performing remote administration using a protocol such as Simple Network Management Protocol (SNMP) the connection should be over a secure encrypted connection (such as layer 2 tunnelling protocol running over IPsec) because SNMP protocols are not secure and It is good practice to use separate Internet connections for different functions: access from Internet to the web site, connection with trusted partners and external access for internal staff (for example, email and web browsing). This allows tailored security measures for every function Let us attempt a quick recall question in the next screen.

3.48 Knowledge Check

This question will help you recall the concepts you learned.

3.49 Control Ownership

What does control ownership mean? All risk should have an owner at a management level that can make decisions on behalf of the organization. The risk practitioner should communicate with the risk owners to: Ensure that they are aware of the risk response that have been implemented, the risk responses that are still pending implementation, and the level of risk that the organization is currently facing Mandate the implementation of new risk mitigation if he or she is not willing to accept the current risk level Let us learn about systems control design implementation in the next screen.

3.50 Systems Control Design Implementation

Well, now that you know what control ownership are, let’s learn about systems control design implementation. As you know that control system is a set of devices that help to manage the performance of other systems. Systems should be designed to: Be secure and Ensure that security controls are built into the system and tested prior to deployment Testing is done to uncover any flaws or risk that may be hidden in the functionality or design of the application or system. We shall look at unit testing in systems control design implementation in the next screen.

3.51 SystemsControl Design Implementation: Unit Testing

After learning about systems control design implementation, let’s learn about unit testing. Unit testing is the testing of each individual component or piece of a system. It is done through white box testing or black box testing. Click each tab to know more about the types of unit testing. White box testing: In this type of testing, the developer has full access and visibility to the code itself or Black box testing: Where the tester cannot see into the code module or application or product to see how it operates Code review should be done where source code is reviewed by a third party to validate compliance with standards and good coding practices. This will detect unauthorized changes made by the programmer and detect inadequate error handing, input validation, or documentation. Let us learn system testing in systems control design implementation in the next screen.

3.52 Systems Control Design Implementation: System Testing

Okay, after learning about unit testing, let’s learn about system testing. System testing of software or hardware is done to evaluate the system's compliance with its specified requirements. System testing is actually black box testing that does not require any knowledge of the inner design of the code or logic. Testing shows how the components work when they are integrated or joined together along with the interfaces between the components and the overall operation of the system. Integration testing tests the system in relation to its overall environment. Say, for example, it can show whether the new or changed system accepts data properly from upstream systems and integrates properly with downstream systems. Unit testing and initial integration testing is often performed in a separate area from the final system testing to: Ensure that the components being tested are not being modified by the developer during the testing process Help test the security functions designed into the project and Ensure that the system has been built according to the design. And, if not built according to design, it should be ensured that deviations from the plan have been documented and approved We shall continue to look at system testing options in the next screen.

3.53 Systems Control Design Implementation: System Testing (contd.)

Let’s look at some testing options. System testing options include: Recovery testing checks the system’s ability to recover after a software or hardware failure The regulatory environment verifies that the system includes provisions for appropriate access controls and does not introduce any security holes that may compromise other systems Security testing refers to the organizational structure and assets and Stress or volume testing tests an application with large quantities of data to evaluate its performance during peak hours We shall continue to look at system testing in systems control design implementation in the next screen.

3.54 Systems Control Design Implementation: System Testing (contd.)

Well, here are some more system testing options. They are: Volume testing studies the impact on the application by testing with an incremental volume of records to determine the maximum volume of records (data) that the application can process Stress testing studies the impact on the application by testing with an incremental number of concurrent users or services on the application to determine the maximum number of concurrent users or services the application can process and Performance testing compares the performance of the system to other equivalent systems using well-defined benchmarks We shall learn about quality assurance in systems control design implementation in the next screen.

3.55 Knowledge Check

This question will help you recall the concepts you learned.

3.56 Systems Control Design Implementation: Quality Assurance

Do you know what quality assurance means? Quality assurance is a planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. A user acceptance test (UAT) is used to: Validate whether the program is meeting user requirements and expectations Highlight problems with the functionality, process flow, or training that may not have been detected earlier in the process Validate the program that delivers the expected functionality in a reliable and secure manner and check whether the program has been developed and documented according to organizational standards and good practices We shall continue to learn about quality assurance in systems control design implementation in the next screen.

3.57 Systems Control Design Implementation: Quality Assurance (contd.)

You will now learn the responsibilities of business representatives. During quality assurance, business representatives have the responsibility of: Conducting final testing and preparation for implementation Testing a beta version of the program as a simulation of the operational environment and conditions and Implementing the program after the final tests of the code have been conducted Let us look at the methods of systems control design implementation in the next screen.

3.58 Systems Control Design Implementation: Others

After you learned about the responsibilities of business representatives, let’s now learn about some methods of systems control design implementation. The methods of systems control design implementation include: Version control Regression testing Test data Fuzzing Separation of development from production Fallback or Rollback Click each tab to more know about systems control design implementation. Version control tracks the current version of the software and checks for previous changes when a new change is implemented and also ensures that the correct version of the source code of the software is being used in compiling the object code for production. Regression testing involves testing the changes to a program to discover any new problems in the operation of the program that were caused by the changes or whether the changes made have inadvertently removed previous fixes. Test data should never use sensitive production data but should be displayed in a manner that makes it unreadable or (obfuscated) this will prevent the disclosure of sensitive data to unauthorized personnel during the testing process. Fuzzing is the process of testing input fields or (controls) of a program. This helps to test the allowable values which enable the tester to observe whether the input validation and process integrity controls are working correctly. Separation of development from production- System development area should be separated from the production area in order to protect the organization from unauthorized or inadequately tested changes. Fallback or rollback -If in case the new system does not function properly due to technical problems, software problems, or other unexpected challenges, the project team should have a fallback plan so that it is possible to roll back to the earlier program or configuration where possible. Let us look at go-live techniques in systems control design implementation in the next screen.

3.59 Systems Control Design Implementation: Go-live Techniques

Well then, you have learned about the methods of systems control design implementation, let’s see how the go-live techniques function. Methods commonly used to enable the transition between versions of a system or application or from one system to another includes: Parallel changeover Phased changeover and Abrupt changeover Click each method to more know about go-live techniques in systems control design implementation. A parallel changeover is done by running both systems simultaneously. This allows the project team to test the reliability and performance of the new system and ensure that it is working correctly before removing the old system from service. The benefits of a parallel changeover are that it minimizes the risk of a failed cutover to the new stems, allows testing of the performance of the new system without affecting production, and allows staff to train on and become familiar with the new system before it is in full production. A disadvantage of a parallel changeover is the cost of maintaining both systems at the same time and the challenge of ensuring that the data are consistent between both systems. A phased changeover is conducted by replacing individual components or modules of the old system with new or modified components. This reduces the risk by gradually rolling out the new modules without impacting the entire system. Depending on the type of system, however, this type of cutover is not always possible. Some of the risk factors that may exist in the phased changeover include: Extension of the project life cycle to cover two systems Change management for requirements and customizations to maintain on-going support of the older system Resource challenges on the IT side (to be able to maintain two unique environments such as hardware, OSs, databases and code) and on the operations side (to be able to maintain user guides, procedures and policies; definitions of system terms, and so on) and Maintaining consistency of data on multiple systems or locations An abrupt changeover is the riskiest changeover process because it may be impossible to roll back if the project fails. In this process, the old system is replaced entirely with the new or modified system at once, and the operation of the old system is discontinued. It involves the following steps: Convert files and programs; perform test runs on the test bed Install new hardware, OS, application system and migrated data Train employees or users in groups Schedule operations and test runs for go-live or changeover The potential risk associated with this technique include: Change management challenges Duplicate or missing records Asset safeguarding Data integrity System effectiveness System efficiency Let us learn more about go-live techniques in systems control design implementation in the next screen.

3.60 Systems Control Design Implementation: Post-implementation Review

Okay, now let’s learn about post-implementation. Post-implementation review is useful for determining whether the project was properly designed, developed, implemented and managed and that the appropriate controls have been built into the system. It should include: Evaluate the projected cost benefits or return on investment(ROI) measurements Assess the adequacy of the system Does the system meet user requirements and business objectives? Have controls been adequately defined and implemented? Assess the development project process Were the chosen methodologies, standards and techniques followed? Were appropriate project management techniques used? Is the risk of operating the system within acceptable risk levels? Develop recommendations that address the system’s inadequacies and deficiencies. Develop a plan for implementing the recommendations. We shall learn about project closeout in systems control design implementation in the next screen.

3.61 Systems Control Design Implementation: Project Closeout

After learning about post-implementation review, let’s now move to project closeout in systems control design implementation. A project closeout is the final inspection, submission of necessary documentation, acceptance, and concluding payment on a project. There are a number of steps in developing project closeout in systems control design implementation. These steps are displayed. Click each tab to know more.   Step 1: Assign any outstanding issues to individuals responsible for remediation and identify the related budget, if applicable. Step 2: Assign custody of contracts, and archive or pass on documentation to those who will need it. Step 3: Survey the project team, development team, users and other stakeholders to: Identify any domains learned that can be applied to future projects. Include content-related criteria such as: Performance fulfilment and project-related incentives Fulfilment of additional objectives Adherence to the schedule and costs Include process-related criteria such as: Quality of the project teamwork Relationships to relevant environments Step 4: Conduct reviews in a formal process. Step 5: Complete a post implementation review after the project has been in use (or in production) for some time and measure the project’s overall success and impact on the business units.     Let us attempt a recall question in the next screen.

3.62 Knowledge Check

This question will help you recall the concepts you learned.

3.63 Controls and Countermeasures

In the previous domains. You learned about risk identification and risk avoidance. Now, there may be situations, when even after implementing adequate measures, risks surface. As such, it is necessary to mitigate risks.   Risk mitigation is accomplished through the use of controls. Controls may be proactive or reactive.   Click each tab to know more. Proactive controls, as the name implies, mean that they attempt to prevent an incident. They are often called safeguards. Reactive controls, as the name suggests are meant to help in recovery after an incident. They are known as countermeasures.   The risk practitioner should provide advice on the selection, design, implementation, testing, and operation of the controls. A control matrix is important in this context.   Let us learn about how controls are grouped in the next screen.  

3.64 Controls and Countermeasures: Control Matrix

Now that you learned to mitigate risks using controls, let’s learn the various types of controls. Controls are grouped into managerial, technical, and physical controls. Within each of those groups of controls are various types of controls that can be used, such as: Directive Deterrent Preventive Detective Corrective Recover Compensating controls An example of a control matrix is shown in the table. Many controls may fit into more than one category. In the next screen, we shall look at control standards and frameworks.

3.65 Controls and Countermeasures: Control Standards and Frameworks

After understanding the various types of controls, let’s learn about the control standards and framework. Control standards and framework are used as a countermeasure in an organization. A control framework: Is used to describe how an organization can achieve compliance in order to meet the requirements of the standard. Is thus an implementation of controls intended to support and protect business operations and preserve asset value. Is as a set of fundamental controls that facilitates the discharge of business process owner responsibilities to prevent financial or information loss in an enterprise. Any control undertaken by the management to mitigate a risk therefore should be monitored and tested to ensure its correct operation and effectiveness. Have standards that are used to benchmark security across the industry sector. Let us look at administrative, technical, and physical controls in the next screen.

3.66 Controls and Countermeasures: Categories of Controls Interactivity

Okay, now let’s learn about categories of controls. The categories of controls include: Physical controls-Devices that are installed to physically restrict access to a facility or hardware such as locks, fences, closed-circuit TV (CCTV), and so on. Administrative controls- These controls are managerial in nature and are related to the oversight, reporting, procedures and operations of a process. They include controls such as policy, procedures, balancing, employee development, and compliance reporting. Technical or Logical controls- Are provided through the use of a technology, equipment, or device. For example, firewalls, network or host-based intrusion detection systems (IDSs), passwords, and antivirus software. In the next screen, we shall look at business continuity and disaster recovery management.

3.67 Knowledge Check

This question will help you recall the concepts you learned.

3.68 Business Continuity and Disaster Recovery Management

Now that you have understood the categories of controls, let's learn about the importance of business continuity planning and disaster recovery management. Effective incident response, business continuity planning, and disaster recovery planning are key requirements necessary in order to mitigate system failure impacts. Business continuity plans (BCPs) and disaster recovery plans (DRPs) should: Offer services in the event of a disastrous disruption and interruptions to business activities. Rigorous planning and resources commitment is necessary in order to plan adequately for such events. Be supported by a formal executive policy stating the organization’s overall target for recovery and empowers the people involved in developing, testing and maintaining the plans. Identification of strategically important business processes is the first step in preparing a new BCP. These are key processes that are responsible for both the permanent growth of the business and for the fulfilment of the business goals. Senior management are responsible for business continuity planning because they are entrusted with safeguarding the assets and the viability of the organization as defined in the BCP or DRP policy. We shall continue to learn about business continuity and disaster recovery management in the next screen.

3.69 Business Continuity and Disaster Recovery Management (contd.)

Business continuity focuses on continuing critical business operations in the event of a crisis and having plans in place to support those operations until the business can return to normal operations. Business continuity planning takes into consideration: The critical operations necessary for the organization’s survival and The supporting human and material resources BCP plans for continuity of operations including: Restoration plans that is used to normalize the business operations whether in a restored or new facility and A DRP used to recover a facility rendered inoperable and relocation of operations Depending on the complexity of the organization, there could be one or more plans to address several features of business continuity and disaster recovery. The plans should be consistent to have a viable business continuity strategy. Let us learn about the alternate processes used in business continuity and disaster recovery management in the next screen.

3.70 Business Continuity and Disaster Recovery Management (contd.)

Let’s now learn some of the alternate processes used in recovery of critical business processes. They are: Displacing less critical work with more critical functions Outsourcing support or a manual process Having sufficient inventory on hand to support operations and Using facilities available at another office or location Business continuity planning is based on BIA as it examines the impact of an outage on the business over time. The impact of the outage on the business (both quantitatively and qualitatively) increases as the length of the outage increases. The sooner the business can return to normal, the less overall impact; however, the cost to return to normal is often the inverse of the length of recovery time taken. The risk practitioner must thus review the process used to determine the BIA to validate its accuracy and consider all of the risk factors. We shall continue to learn more about business continuity and disaster recovery management in the next screen.

3.71 Business Continuity and Disaster Recovery Management (contd.)

Let’s now move on to disaster recovery planning. Disaster recovery planning is the recovery of business and IT services within a predefined schedule and budget following a disaster. The time frames for recovery are based on the length of outage time and the cost of recovery that the management is willing to accept. The risk practitioner should review the BCP and DRP to ensure that they: Are up to date Reflect risk scenarios and business priorities Have been tested Testing the plans is done to uncover any vulnerability and provide the experience needed for team members to effectively enact the BCP or DRP plans. Let us learn about exception management in the next screen.

3.72 Knowledge Check

This question will help you recall the concepts you learned.

3.73 Exception Management

Exception management is applied to give employees the responsibility to take decisions and to accomplish their work or projects by themselves. Policies, procedures, and standards are essential part of operating secure systems to attain a secure state. There are cases in which an exception to policy, procedure or standard is necessary. Exceptions should only be allowed through a formal process that requires approval from a senior manager and should be documented. The risk level is unknown if exceptions are not documented and uncontrolled thus may be a hidden vulnerability. The risk practitioner must ensure that an exception management process is in place and is being followed and The exceptions should be removed when they are no longer needed. We shall look at risk ownership and accountability in the next screen.

3.74 Risk Ownership and Accountability

Let’s now look at risk ownership and accountability. The risk owner should identify risks and escalate where necessary to the appropriate level of management. The documentation of all risk and the assessment of the priority of the risk for risk response results from completion of the risk assessment phase. Each risk must be linked to an individual who has the responsibility to accept ownership of the risk. The risk owner: Must take decisions depending on the best response to the risk identified. Must be at a level in the organization where they are authorized to make decisions on behalf of the organization and where they can be held accountable for those decisions. Must be with an individual and not with a department or the organization as a whole to ensure accountability. In the next, screen we shall learn about inherent and residual risk.

3.75 Inherent and Residual Risk

After learning about risk ownership and accountability, let’s learn about inherent risk. In business, some degree of risk is unavoidable even though some business processes have a higher level of inherent risk than others. Risk is inherent in everything; however, the degree of risk varies from one activity, product, or service to another. The risk practitioner should: Understand the inherent risk Be able to assess the current risk and if necessary Mitigate the risk to reduce it to an acceptable level of residual risk Let us continue to learn more about inherent and residual risk in the next screen.

3.76 Inherent and Residual Risk (contd.)

Let’s now understand further what inherent risk means. Inherent risk is the risk level or exposure without taking into account the implementing controls that have been undertaken by the management. The risk practitioner should therefore examine: The current risk profile of the organization including the inherent risk The levels of residual risk, and The correct operation and monitoring of the controls in place Areas with a higher level of inherent risk may need additional controls to reduce the risk level to acceptable levels. For instance, an area that handles financial transactions. Such areas often require stronger physical controls, more monitoring, SoD, and background checks for employees. Let us continue to learn more about inherent and residual risk in the next screen.

3.77 Inherent and Residual Risk (contd.)

In addition to understanding inherent risk, you should also know what risk mitigation refers to. The key objective of mitigating controls is to reduce the level of risk to an acceptable level. Residual (remaining) risk: Is the level of risk that remains after the implementation of controls?

3.78 Quiz

The quiz action will help you to check your understanding of the concepts covered.

3.79 Summary

Here is a quick recap of what we have learned in this domain: Risk response is defined so as to align risk with the defined organization’s risk appetite. Risk acceptance is a decision made by senior management to recognize the existence of risk and knowingly decide to allow the risk to remain without mitigation. Risk mitigation refers to actions taken to reduce the impact and frequency of a risk. The risk response chosen by the management is often based on the evaluation of response options. Cost-benefit analysis is used to justify the expense associated with the implementation of controls.

3.80 Summary (contd.)

Risk management and implementation of controls should not affect business operation, or either of its objective but rather the risk response should ensure compliance with standards of risk management Encryption is used to protect the confidentiality of data by making data unreadable to unauthorized personnel, or protecting the integrity through hashing and digital signature. Systems should be designed to be secure, and the development process should ensure that security controls are built into the system and tested prior to deployment. Inherent risk is the risk level or exposure without taking into account the implementing controls that have been undertaken by the management. Residual risk is the level of risk that remains after the implementation.

3.81 Conclusion

You have come to the end of this domain. Next, you will learn about Risk and Control Monitoring and Reporting.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*