Risk Assessment Tutorial

2.1 Risk Assessment

Hello! Welcome to the domain Risk Assessment of Certified in Risk and Information Systems Control (CRISC®) Course offered by Simplilearn. This domain covers information technology risk assessment. The focus of this domain is that the CRISC candidate should be able to analyze IT risk to determine how it affects business objectives.   Let us look at the objectives of this domain in the next screen.

2.2 Objectives

After completing this domain, you will be able to: Discuss, identify, and apply risk assessment techniques Detail risk analysis scenarios Discuss risk evaluation, impact assessment, and third party vendor management Detail IT operations management Explain system development lifecycle List emerging technologies and discuss enterprise architecture   Let’s now begin this domain by learning about task statements in the next screen.

2.3 Task Statements

As you have already learned in previous domains, 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 task statements under Risk Assessment as prescribed by ISACA® are: Determine likelihood and impact of risk by analyzing organization risk scenarios Identify how current controls mitigate against IT risk Identify gaps between current and desired state of the IT risk environment through risk and control analysis Ensure clear accountability on risk ownership Ensure outcome of risk assessments is communicated to enable risk based decisions and Ensure that the risk register is regularly updated by the results of risk assessments    In the following screen, we will look at knowledge statements.

2.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 a information security professional must have a thorough knowledge of. These statements help the security professional to perform the tasks required. Do you know what information a CRISC candidate must have about knowledge statements? Click each tab to know more. Tab 1: The CRISC® candidate should have knowledge of: Enterprise system architecture as well as business objectives Contractual requirements Vulnerabilities and threats Risk identification and classification methods How to develop various risk scenarios and Concept relating to risk events Tab 2: Concept relating to risk events Contents of risk register Appetite to risk and tolerance How to analyze risk Organizational culture, policies, structure, and assets Business process review methodology Capability assessment models and Data collection and analysis Tab 3: Inherence and residual risk Handling exceptions to organizations standards Risk assessment and response methods Principles of information security such as triad of confidentiality, availability, and integrity System development methodology Key performance and risk indicators and Risk monitoring and reporting as well as best practices Tab 4: Types of information system controls and frameworks Monitoring control weaknesses and reporting on them Carrying out assessments on controls Various control activities

2.5 Knowledge check

This question will help you recall the concepts you learned.

2.6 Risk Assessment Techniques

Risk assessment is a process that help to determine the quantitative or qualitative estimate of risk related threat. There are several approaches to conduct risk assessment. Approaches to risk assessment include scenario analysis, Bayesian statistics, bow tie analysis, event tree analysis, structure or semi structured interviews, business impact analysis, and fault tree analysis.   Click tab to know more risk assessment technique.   Scenario analysis uses possible future situations in scenario analysis. Bayesian statistics uses the theory of probability based on prior distribution data. Bow tie analysis is used in cases where links between causes, controls and consequences are drawn. Bottom up approach uses inductive reasoning to assess the probability of events resulting in possible outcomes in event tree analysis. Structured or semi structured interviews uses “what if” brainstorming guided questions. Business impact analysis is used to determine the effect of losing a certain resource, which is expressed over a period of time. Fault tree analysis is a top down review of the means by which an event would occur.   We shall continue looking at some more risk assessment techniques in the next screen.

2.7 Risk Assessment Techniques (contd.)

Okay, let’s learn some more approaches to risk assessment. These include hazard analysis and critical control points, cause and consequence analysis, cause-and-effect analysis, hazard and operability study, checklists, and sneak circuit analysis. Click each tab to know more about risk assessment technique.   Hazard analysis and critical control points is a system of preventing risk and assuring the quality, safety and reliability of a process by determining hazards and identifying control points in the processes Cause and consequence analysis combines a mix of top down and bottom up approaches (fault tree and event tree analysis) In cause-and-effect, analysis factors that contributed to an event are analyzed. Hazard and operability study through looking at deviations to existing process. Checklists of the risks that are likely to affect an organization Sneak circuit analysis to identify design errors or sneak conditions that are not easy to identify through system tests We shall continue looking at risk assessment techniques in the next screen.

2.8 Risk Assessment Techniques (contd.)

Approaches to risk assessment also include environmental risk assessment, structured “what if” technique, preliminary hazard analysis, reliability-centered maintenance, root cause analysis, and the Delphi method.   Click each tab to know more about risk assessment technique.   Environmental risk assessment is a type of process that helps in predicting whether there may be a risk of adverse effects on the environment by any or a particular chemical substance. Structured “what if” technique uses brainstorming activities in a workshop set up. Preliminary hazard analysis, analyses the threats that could harm an enterprise. Reliability-centered maintenance focuses on failures in a physical asset Root cause analysis focuses on uncovering the root cause of a particular event. Delphi method relies on getting opinions from experts.   Let us look at risk scenarios analysis in the next screen.

2.9 Risk Scenarios Analysis

So, now that you have learned the approaches to risk assessment, let’s understand risk scenario analysis. Scenario analysis is a process that helps to analyze future events by considering alternative possible outcomes. Certain aspects of risk scenario analysis are: Developed during risk identification Useful to communicate In addition, they calculate the impact of a risk event and help in early detection of an incident.   Click each tab to know more about aspects of risk scenario analysis.   Risk scenarios are developed during risk identification and are used to identify and describe potential risk events. The scenarios are useful to communicate with the business and gather input data required to understand the potential or probable impact of the risk event if it were to occur. It is hard to calculate the impact of a risk event because there are various uncertain factors affecting the outcome of the event. The impact may be minimized and the recovery process may be rapid if the event is detected quickly and appropriate measures are taken to contain it. The incident could cause severe damage and result in much higher recovery costs if the organization is unable to detect it promptly. We shall look at how organizational structure affects risk scenario analysis in the next screen.

2.10 Risk Scenarios Analysis: Organizational Structure and Culture

The structure and culture of the organization are contributing factors in risk prevention, risk detection, and risk response. Risk prevention: A mature organization has policies and procedures and an effective reporting and notification structure in place to detect, notify, and escalate a situation effectively. Risk detection: The risk management function should have an enterprise wide mandate that allows the risk management team to review and provide input into all business processes. Risk response: They should participate in the incident management activities and be responsible for investigating incidents to ensure that all domains are learned and to improve incident response planning, detection and recovery. We shall look at how policies affects risk scenario analysis policies in the next screen.

2.11 Risk Scenarios Analysis: Policies

You learned the aspects of risk scenario analysis. Now, let’s learn why policies are adopted within an organization. Policies in an organization provide authority to the risk management, audit, and security teams of the organization to perform their job responsibilities. The policies of the organization should clearly define the senior management position toward the protection of information. The risk practitioner should assess the risk associated with the policy framework of the organization and provide recommendations as necessary. We shall look at the layers of policies in the next screen.

2.12 Risk Scenarios Analysis: Policies (contd.)

Well, there are two prominent layers of policies, high-level policy and next level of policies. Click each tab to know more about policy layer.   A high-level policy is issued by the senior management as a way to address the objectives of the organization’s mission and vision statement. The next level of policies is technical and functional and includes specifics regarding the use of technology, that is., a remote access policy, acceptable use policy, and password and access policy. We shall look at how standards and procedures affects risk scenario analysis in the next screen.

2.13 Risk Scenarios Analysis: Standards and Procedures

Let’s now learn about the standards and procedures that affect risk scenario analysis. Standards and procedures support the requirements defined in the policies set by the organization. A standard is defined as a mandatory requirement, code of practice, or specification approved by a recognized external standard : organization, such as the International Organization for Standardization (ISO). A procedure is a document containing a detailed description of the steps necessary to perform specific operations in conformance with applicable standards. Procedures are defined as part of processes. They describe the consistent and measureable ways that an operation is conducted so that the risk practitioner can be assured that operations are performed properly. A lack of standards and procedures will result in undependable, inconsistent operations and may result in risk due to not detecting a risk event, noncompliance with regulations or difficulty preventing an attack. We shall look at how technology affects risk scenario analysis in the next screen.

2.14 Knowledge check

This question will help you recall the concepts you learned.

2.15 Risk Scenarios Analysis: Technology

Alright, you will now learn about some areas of technology affects risk scenario assessment. Many organizations use legacy technologies, which can be difficult to support. Some of the considerations that affect risk assessment related to technology include: Ability to patch Age of equipment Expertise available for maintenance Variety of vendors or suppliers Documentation of systems Availability of replacement parts Ability to test systems or equipment Operating environment and user expertise   In the next screen, we shall look at how lack of architecture affects risk scenario analysis.

2.16 Risk Scenarios Analysis: Architecture

Architecture analysis is a process of reducing risk at an early stage to determine whether the system matched the desired business and quality requirements. The development of an enterprise wide approach to risk management, architecture and business continuity is a key factor in the maturation of the processes and practices of an organization. It promotes consistency, repeatability, compliance, accountability, and visibility to management of the organization. A lack of architecture often results in: Controls that conflict with one another Controls that overlap Unidentified single points of failure Unidentified methods to bypass controls Inadequate network isolation We shall look at controls in analyzing risk in the next screen.

2.17 Risk Scenarios Analysis Controls

Controls are implemented to mitigate risk or to comply with regulations. A review of the controls evaluates whether the controls are working effectively to mitigate the risk and that there is correct balance between technical, administrative, and physical or operational control types. The two areas of implementation are implementing a technical control and implementing technological control. Click each tab to know more. This refers to implementation of a technical control, such as a firewall, that requires correct training for the staff, correct procedures for configuring the control, assignment of responsibilities for monitoring the control and reviewing the log data, and regular testing of the control functions. This requires adequate coinciding controls to ensure that the technology control is being effectively managed. We shall continue looking at controls in the next screen.

2.18 Risk Scenarios Analysis Controls (contd.)

Controls can be categorized into several categories. They are: preventive, corrective, compensating, detective, deterrent, and directive. Click each tab to know more. Preventive controls inhibit attempts to violate security policy and include such controls as access control enforcement, encryption, and authentication. Corrective controls remediate errors, omissions, and unauthorized uses and intrusions, once they are detected. Backup restore procedures enable a system to be recovered if harm is so extensive that processing cannot continue without recourse to corrective measures. Compensating controls are alternate form of control that corrects a deficiency or weakness in the control structure of the enterprise. Compensating controls may be considered when an entity cannot meet a requirement explicitly, as stated, due to legitimate technical or business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other controls. Adding a challenge response component to weak access controls can compensate for the deficiency in the access control mechanism. Detective controls warn of violations or attempted violations of security policy and controls such as audit trails, intrusion detection methods and checksums Deterrent controls provide warnings that can discourage potential compromise, such as warning banners on login screens or offering rewards for the arrest of hackers Directive controls mandate the behavior of an entity by specifying what actions are, or are not, permitted; a directive control is often considered a type of deterrent. A policy is an example of directive control. Next, we shall look at main methods of risk analysis in the following screen.

2.19 Risk Analysis Methodologies

There are two main methods of risk analysis: quantitative and qualitative. Each method has challenges, and many organizations use a hybrid of the two methods, which is called semi quantitative. We shall look at the first method of risk analysis namely, quantitative risk assessment in the next screen.

2.20 Risk Analysis Methodologies: Quantitative Risk Assessment

Quantitative risk assessment is often based on certain aspects such as calculation of the impact of a single risk event and scenarios or descriptions of situations. Click each tab to know more. This refers to the calculation of the impact of a single risk event and on what the event would cost including direct costs, such as lost sales and indirect costs, such as loss of competitive advantage or damage to reputation. To properly use the data obtained from a quantitative risk assessment, the cost of a risk is often calculated on an annual basis. The calculation of the cost of an event is unpredictable and depends on the effectiveness of the risk prevention, detection, and response process. This is usually based on scenarios or descriptions of situations that may have occurred or may occur. The intention of the scenarios is to elicit feedback from all the stakeholders regarding the impact of the scenario on the operations. The feedback is usually not numeric and is based on a range of values such as very high, high, moderate, low, and very low. We shall look at the next method of risk analysis, which is qualitative risk assessment in the following screen.

2.21 Risk Analysis Methodologies: Qualitative Risk Assessment

Let’s understand what qualitative risk assessment is? In qualitative risk assessment, the probability of a risk event that may occur and the impact that it may have is detected. The development of risk scenarios may be based on threats, vulnerabilities, or asset or impact. Click each tab to know more. A threat-based scenario examines a risk event from the basis of what threat sources (threat agents) exist and the threats that could be launched against the organization. The threat-based scenario would identify the potential method of attack, the vulnerabilities exploited, the intent, and skill of the attacker and the potential damage to the assets affected. This method is especial K beneficial when examining the emergence of new threats and determining the risk related to advanced persistent threats (APTs). A vulnerability-based approach examines the organization’s known vulnerabilities and then attempts to determine the threats that could exploit those vulnerabilities and their impact. This is especially valuable after completing a vulnerability assessment to determine the severity of the vulnerabilities. An asset or impact approach is based on the identification of critical (availability) and sensitive (confidentiality and integrity) assets and the potential ways that an asset could be damaged. This approach is also used in BIA. A BIA is based on determining the impact of a risk event on an asset (usually a product or service provided by the organization) over time. Let’s learn about semi quantitative risk assessment in the next screen.

2.22 Knowledge check

This question will help you recall the concepts you learned.

2.23 Risk Analysis Methodologies: Semi-quantitative Risk Assessment

Let’s learn about semi quantitative risk assessment. It is important that both qualitative and semi quantitative risk assessments support the business representatives who are providing input data with meaningful ways to determine the difference between the various risk levels. In a semi quantitative risk assessment: The values of qualitative and quantitative risk assessment are combined. The risk practitioner creates a range of values that are used to assess risk. It is important that both qualitative and semi quantitative risk assessments support the business representatives who are providing input data with meaningful ways to determine the difference between the various risk levels. We shall continue to look at how impact is assessed in a semi quantitative risk assessment in the next screen.

2.24 Risk Analysis Methodologies: Semi-quantitative Risk Assessment(contd)

Okay, now let’s learn about the criteria used to assess the impact in a semi quantitative risk analysis. When assessing the impact, many criteria can be used, including: Financial loss such as fines, lost sales and contract penalties Damage to reputation such as brand and customer confidence Injury or loss of life Lost opportunities such as competitive advantage and Research Lost productivity Cost to investigate and recover Future costs due to new procedures We shall learn about risk ranking in the next screen.

2.25 Risk Ranking

Now that you have learned about risk analysis methodologies, let’s move on to risk ranking. After the results of a risk assessment are compiled, a risk ranking is completed. This risk ranking is used to direct the risk response effort. Risk ranking is derived from a combination of all the components of risk including: Likelihood of attack success determined by the effectiveness of controls Level of impact of an attack Recognition of the threats Characteristics or capabilities of a threat source Vulnerabilities and their severity When combined together, these indicate the total level of risk associated with a threat. Let’s now learn about the role of OCTAVE approach in the next screen.

2.26 OCTAVE®

Alright, you will now learn about OCTAVE® as a risk assessment approach. Operationally Critical Threat Asset and Vulnerability Evaluation® or OCTAVE® is an approach used to understand, assess, and address information security risk. The main roles of OCTAVE include: Identify critical information assets Focus on risk analysis activities on critical assets Consider the relationships among critical assets, the threats, and the vulnerabilities Evaluate risk in operational context Create practice-based protection strategy risk mitigation plans for organizational improvement Reduce the risk to the organization’s critical assets   Let us attempt a quick recall question in the next screen.

2.26 OCTAVE®

Alright, you will now learn about OCTAVE® as a risk assessment approach. Operationally Critical Threat Asset and Vulnerability Evaluation® or OCTAVE® is an approach used to understand, assess, and address information security risk. The main roles of OCTAVE include: Identify critical information assets Focus on risk analysis activities on critical assets Consider the relationships among critical assets, the threats, and the vulnerabilities Evaluate risk in operational context Create practice-based protection strategy risk mitigation plans for organizational improvement Reduce the risk to the organization’s critical assets   Let us attempt a quick recall question in the next screen.

2.27 Knowledge Check

This question will help you recall the concepts you learned.

2.28 Control Assessment: Current State of Controls

You will now learn how to determine the current state of risk. To propose risk mitigation actions, a risk practitioner must first analyze the current state of risk in an organization. Current state refers to the condition of the program at a point in time, so the risk assessment is only valid at the time the risk state is measured. The following are used to determine the current state of risk: Regular reports generated by controls Results of control testing activities Results of incident management programs Let’s take look at the role of the risk practitioner in managing current state of controls.

2.29 Control Assessment: Current State of Controls (contd.)

The risk practitioner must undertake certain reviews in order to manage and control risk. This includes review of the state of risk and review of the current and desired level of risk. Click each tab to know more.   Review risk to determine the state of the risk on a regular basis. This is reported to the management in the form of a scheduled report. Review current risk levels and contrast the current level with the desired state or level of acceptable risk. This is essential to determine the reason for the gap, and solutions recommended to address the disparity.   Now that you have learned about the current state of risk, let’s take a look at the tools used in the process to determine the current state of IT risk.

2.30 Control Assessment: Current State of Controls (contd.)

Right then, let’s look at the different tools used by a risk practitioner to identify the current state of IT risk. Some of the tools used by the risk practitioner to determine the current state of IT risk are: Audits Control tests conducted by the control owner or custodian Incident reports IT operations feedback Logs Media reports of new vulnerabilities and threats Observation Self-assessments Third-party assurance User feedback Vendor reports Vulnerability assessments and penetration tests   Let’s take a look at logs: tools to monitor controls and detect risk in the next screen.

2.31 Control Assessment: Logs

Do you know what logs are? Logs are one of the most valuable tools to monitor controls and detect risk but are underutilized due to the following reasons: They can be hard to search for relevant information They may not be enabled They may not contain the right or appropriate data They are modified or deleted before being read They have too much data Let’s now know the importance of reviewing logs in the next screen.

2.32 Control Assessment: Logs (contd.)

After learning what logs are, let’s understand the contents of a log. Reviewing of logs can help identify risk-relevant events and can detect compliance violations, suspicious behavior, errors, probes or scans, and abnormal activity. Logs must be preserved for forensic analysis. A log should contain a record of all important events that occur on a system, such as: Login or logout Changes to data Changes to permissions System start-up or shutdown Errors or violations Job failure Now that you have seen the importance of logs, lets learn the types of assessments to manage current state of controls.

2.33 Current State of Controls: Vulnerability Assessments and Penetration Testing

The two important types of assessments used in managing current state of controls are: Vulnerability assessment and Penetration tests Let’s learn what vulnerability assessment and penetration tests mean. The vulnerability assessment is a careful review of the security controls for a system with the intent of discovering potential weaknesses or gaps. It helps to produce a list of potential vulnerabilities that must be reviewed, prioritized, and possibly mitigated. On the other hand, a penetration test identifies areas that may need immediate mitigation; where changes are required to procedures, policies, configurations, architecture; and where more training is required. It is a focused test that attempts to break into a system through a potential vulnerability. Let’s now learn about the types of vulnerabilities.

2.34 Control Assessment: Vulnerability Assessments and Penetration Testing

Okay, let’s learn the different types of vulnerabilities. There are various types of vulnerabilities. The possible vulnerabilities include: Buffer overflows arises when there is too much data Susceptibility to injection attacks Unlocked server rooms given that access to server rooms can allow an attacker to steal equipment and circumvent passwords Unpatched systems- may lead to a serious breach of data and availability and financial loss Exposed cabling- can allow an attacker to intercept communication and take ownership Sensitive data left on unattended desks or screens- may be vulnerable to disclosure, modification, destruction or loss Open ports or services that are not required-they may be used as an attack vector by an adversary or be misused by an employee Let us attempt a quick recall question in the next screen. 

2.35 Knowledge Check

This question will help you recall the concepts you learned.

2.36 Risk Evaluation and Impact Assessment: Risk and Control Analysis

You will now understand the tasks of a risk practitioner. The basic tasks of a risk practitioner include comparing the current state of risk, understanding the risk acceptance level, and identifying and documenting findings. Click each tab to know more about task of a risk practitioner. Comparing the current state of risk: Comparing the current state of risk against the desired state of risk, including a review of the effectiveness of controls to mitigate risk. The desired state of IT risk is closely linked to the risk acceptance level set by senior management. Understanding the risk acceptance level: The risk practitioner must learn what the risk acceptance level of the organization is and then compare the current level of risk with the level of risk that is acceptable to management. Identifying and documenting findings: The risk practitioner must identify and document findings and provide suggested means of mitigation where the current level of risk exceeds the acceptable risk level. In the next screen, we will learn about the challenges of data analysis.

2.37 Risk and Control Analysis: Data Analysis

The challenges of data analysis start with the completeness and trustworthiness of the data. The risk practitioner should identify certain aspects of data thoroughly that include: Are all the data available? Have any of the data been altered or changed? Are the data in the correct format? Are the data based on measuring important factors? The risk practitioner should be attentive to the trends of events in the data sources when analyzing data to determine risk levels, so as to identify any emerging problems and mitigate.   Let’s now learn about the commonly used approaches to data analysis.

2.38 Risk and Control Analysis: Data Analysis

Now that you learned about the role of a risk practitioner in analyzing data, let us understand the types of data analysis approaches. The common types of data analysis approaches include cause-and-effect analysis, fault tree analysis, and sensitivity analysis. Click each tab to know more. Cause-and-effect analysis: A predictive or diagnostic analytical tool that is used to explore the root causes or factors that contribute to positive or negative effects or outcomes and identify potential risk. Fault tree analysis: A technique that provides a systematic description of the combination of possible occurrences in a system, which can result in an undesirable outcome (top-level event) and combines hardware failures and human failures. Sensitivity analysis: A quantitative risk analysis technique that: Helps to determine which risk factors potentially have the most impact and examines the extent to which the uncertainty of each element affects the object under consideration when all other uncertain elements are held at their baseline values. Let’s now learn about the methods by which you can analyze risk and control analysis in the next screen.

2.39 Risk and Control Analysis: Threat and Misuse Case Modelling

Let’s now move on to the types of risk and control analysis. There are two prominent types of risk and control analysis. They are: Threat and misuse case modelling Alright then, let’s understand each of these risks. Threat modelling examines the nature of the threat and potential threat scenarios. It is done by mapping the potential methods, approaches, steps and techniques used by an adversary to perpetrate an attack. An example of threat modelling is the “ping of death” attack. Case modelling examines how a system will function and provide “use” for the users. Misuse case modelling looks at all the possible errors, mistakes or ways a system can be misused. Understanding misuse cases can ensure that a system is built with resiliency and the ability to handle errors and misuse.   Say for example, the Internet control message protocol (ICMP) packet was designed as a tool for system and network administrators to test network connectivity. However, by altering the size of an ICMP packet, an attacker is able to build an attack tool that could disable a victim’s system. The ICMP tool was never designed for such a purpose, but the attackers learned how to use it improperly.   Let’s learn about process of root cause analysis in the next screen.

2.40 Risk and Control Analysis: Root Cause Analysis

Do you know what root cause analysis means? Root cause analysis is a process of diagnosis to establish the origins of events, which can be used for learning from consequences, typically from errors and problems. Root cause analysis discovers the core, or root, of a problem and ensures that the actions taken are focused on fixing the source of the problem. It also examines the reasons why a problem exists or a breach has occurred and seeks to identify and resolve any underlying issues.   A prudent manager examines the root cause of an incident to discover the conditions and factors that led to the event, rather than react to the symptoms of the problem.   In addition to root cause analysis, you can also perform gap analysis to know what the ideal state is and what the current state is. Let’s now learn about gap analysis in the next screen.

2.41 Risk and Control Analysis: Gap Analysis

Let’s now look at gap analysis. Do you know the importance of gap between the current and desired state? It is important to understand the gap between the current and desired state to know the various projects that must be undertaken and the milestones that must be met before the goal is reached. Gap analysis identifies the gap or difference between the desired and current state so that corrective action can be taken if required. It is based on documenting the desired state or condition of risk that the management wants to reach and then carefully analyzing and evaluating the current condition of the organization. Let us learn how to determine the desired state of risk using gap analysis in the next screen.

2.42 Risk and Control Analysis: Gap Analysis (contd.)

As you know, there are various ways to measure state. These can be based on key goal indicators (KGIs), key performance indicators (KPIs), international standards, good practices, or compliance. Some of the methods used by the risk practitioners to determine the desired state of risk include: Interviews with management Regulations and legislation International standards and good practices Policies Key performance indicators (KPIs) and Key risk indicators (KRIs) In the next screen we will learn about third-party management.

2.43 Third-Party Management

After learning about gap analysis, let’s learn about third-party management. Outsourcing business functions such as security and IT to third-party providers helps to address the organization’s requirements in a more efficient and cost-effective manner. This includes cloud-based services, applications development, security monitoring, and so on. It is the responsibility of the outsourcing company to safeguard against any breach. In order to protect its intellectual property, the organization must use nondisclosure agreements or NDAs. This helps in preventing disclosure to unauthorized personnel. NDAs are relevant when a penetration test has been done that could be used to perpetrate during attack on the organization.   Let’s learn about how to deal with third-party outsourcing in the next screen.

2.44 Third-Party Management: Outsourcing

Okay, now let’s learn how to deal with third-party outsourcing. There are certain things you must consider when dealing with third-party outsourcing. They are: The decision to outsource technology functions should be carefully considered from a risk and regulatory perspective. All security requirements as well as provisions for liability and reporting should be addressed by the outsourcing contracts. Backups and disaster recovery plans or DRPs must be put in place because the outsourced services can fail like any other service. The organization should ensure that the third-party is compliant with good practices of data security by performing external audits and having the right to audit. The jurisdiction for any disagreements with the provider must be addressed by the legal requirements. The regulations in the host country regarding disclosure must be addressed by the agreements such as law enforcement, data transmission, and storage.   Let’s learn about cloud service in the next screen.

2.45 Cloud

Alright, let’s now learn about the cloud services. Cloud is a service formerly known as remote data hosting. The cloud refers to the use of the Internet to transmit data to a remote location for processing or storage. Some of the cloud services available include: Infrastructure as a service or IaaS Software as a service or SaaS Platform as a service or PaaS and Storage on demand All agreements between the suppliers and service providers must address the security and regulatory requirements. Let’s learn more about contractual requirement within the context of third-party management in the next screen.

2.46 Knowledge check

This question will help you recall the concepts you learned.

2.47 Third-Party Management: Contractual Requirements

Third-party management is not limited to outsourcing. You need to comply with certain the terms of the contract lies between the two organizations who have a contact in place. These include: Service level agreements (SLAs) for activities. These SLAs are part of service contracts. Outsourcers and third-party affiliate review which is a type of performance based marketing Right to audit clauses. Audit clauses are mostly included in long-term contracts Security and BCP or DRP reviews. Both are equally important. While BCP review comprises of planning and processes associated with a business. The DRP review, as its name rightly suggests, deals with recovering key IT resources Security and continuity requirements Staffing reviews vital for evaluating and ranking the staff. Regulatory review essential for eliminating overlaps and gaps Right for early termination. This is used in cases where employee contracts are contractual. Let’s learn more about contractual requirement in the next screen.

2.48 IT Operations Management

In cases where the requirements are contractual, internal review teams are enlisted for verifying the contractual requirements. Failure to meet the contractual or regulatory requirements with customers puts the organization in danger of: Suffering from reputational damage Losing business Facing penalties Let us learn about assessing risk of the organization in the next screen.

2.49 IT Operations Management (contd)

In order to avoid the dangers faced due to failure to meet the contractual requirements, the internal review teams must also assess the risk of the organization when the contractual requirements are not met. This includes: Inability to respond promptly to an incident Conflicting demands from multiple customers. Ability to prioritize and focus on demands is very important in such cases. Loss of key personnel. Contingency plans must be kept handy to tackle situations like these Let us learn about System Development Lifecycle in the next screen.

2.50 System Development Lifecycle

System Development Lifecycle or SDLC is a method used to support the development of projects and systems. SDLC describes the project structure in phases and helps in project management and audit. There are five phases in the System Development Lifecycle.   Click on each phase to know more. Phase 1: This is the initiation stage where the need, purpose, and scope for the IT system is expressed and documented. The identified risk is used to support the development of the system requirements, including security requirements and a security concept of operations (strategy). Phase 2: This is the development and acquisition stage where the IT system is designed, purchased, programmed, and developed. Risk identified during this phase can be used to support the security analyses of the IT system that may lead to architecture and design trade-offs during system development. Phase 3: This is the implementation stage where the system security features must be enabled, configured, verified and tested. The risk management process supports implementation against its requirements and within its modeled operational environment. Phase 4: This is the operation and maintenance phase where the system performs its functions. Typically, the system will undergo periodic updates or changes to hardware and software; the system may also be altered in less obvious ways due to changes to organizational processes, policies, and procedures. Phase 5: This is the disposal phase, which involves the disposition of information, hardware, and software. Activities may include moving, archiving, and destroying information. Let’s discuss some more aspects about software development lifecycle in the next screen.

2.51 System Development Lifecycle (contd.)

SDLC is a framework that is basically comprised of tasks performed at every step of the system development process. Some of the main tasks during SDLC include: Business impact analysis such as the impact an outage can have on critical business processes Vulnerabilities awareness within the operational environment Securing the process of information systems development such as training staff and secure code practices, secure environment Privacy impact assessment for example, the sensitive data stored, processed, and transmitted by the system, and the laws and regulations that apply Categorizing the proposed system security for example, requirements for confidentiality, integrity, and availability In the next screen, we shall continue to discuss more about software development lifecycle.

2.52 System Development Lifecycle (contd.)

Not every SDLC project is successful. There are times when a project may fail. Some of the reasons system development projects fail include: Change of system requirements such as unclear initial requirements, scope change, and new business priorities Limited resources such as trained staff or budget Non performance of technology Underestimation of project complexity Poorly managed resources, that leads to lack of accountability, leadership, and oversight Not recognizing symptoms of failure Lack of coordination with suppliers Dependencies on suppliers, outsourcers, communications providers, technology that may lead to delivering on time. In the next screen, we shall look at emerging technologies.

2.53 Emerging Technologies

Emerging technologies act as catalysts in changing the future of an organization. Today, various organizations both old and new are embracing them to take a step forward and excel in their respective fields. Certain aspects associated with emerging technologies include: Inflated expectations Potential risk and controls Assess organization approach Management of risk Click on each aspect to know more.   Inflated expectations of the utility and maturity of new technology influences and builds pressure to implement the technology. This is done while focussing on product functionality and not addressing the security requirements. Potential risk and controls for the application of emerging technologies should be considered. The risk practitioner should assess the organization’s approach to accepting new technologies and the attitude of the stakeholders toward securing the new technologies The change control process should be well-managed to ensure that the security team validates the security impact of new technologies to be implemented.   Let’s continue to learn about emerging technologies in the next screen.

2.54 Emerging Technologies (contd.)

Every organization must have a rule book when it comes to dealing with third-party outsourcing. Some of the prominent rules they should pay attention to include focusing on include the business risk, controlling new technologies, and validating the security impact.   Click on each aspect to know more about emerging technologies.   The organization should not lose sight of the business risk involved while deploying new unproven technologies resulting from inflated expectations of its utility. Pressure to implement new technologies is controlled by forecasting practices considering potential risks and controls to facilitate value delivery from the application of these technologies.  As part of the change control processes, the security team should validate the security impact of the change and adopt appropriate security control measures’.   Let us attempt a quick recall question in the next screen.

2.55 Knowledge Check

This question will help you recall the concepts you learned.

2.56 Enterprise Architecture

Enterprise architecture or EA helps generate a view of the current state of IT, establish a vision for the future, and formulate a strategy to get there. The risk associated with system is a combination of the risk associated with each element that makes up an IT system. The key components of the control environment must answer some very basic questions. Also called as the Four AREs, these questions are essential for assessing decisions. They include: Are we doing the right things? Are we doing them the right way ? Are we getting them done well? Are we getting the benefits? These four Ares also serve as a structured framework for assessing value. Let us look at enterprise architecture hardware equipment and devices in the next screen.

2.57 Enterprise Architecture: Hardware

The enterprise architecture hardware comprises of equipment and devices that process, store, and transmit data. This includes: Random access memory or RAM Read-only memory or ROM Firewalls and gateways Keyboards Monitors Central processing units or CPUs Motherboards and Networking components, such as switches, routers, and so on Now, let us look at some risks associated with hardware.

2.58 Enterprise Architecture: Hardware (contd.)

Risk associated with hardware includes: Physical access: The ability to access server rooms, network cabling, information systems equipment, and buildings can allow attackers to take ownership of the systems Hardware failure will result in system unavailability. This could further result in system malfunctioning. Lost, misplaced or stolen hardware can lead to system malfunctioning Hardware that is not discarded in a secure manner Sniffing traffic can enable an attacker to capture information being exchanged Unauthorized hardware which may not meet the organization security requirements Now, let us take a look at some more risks associated with hardware.

2.59 Enterprise Architecture: Hardware (contd.)

There are various risks associated with hardware. Let’s take a look at some of them: Poor architecture as system may not interface correctly. Poorly maintained hardware may have dust or other environmental hazards accumulated and thus may not function correctly. Misconfigured hardware may leave some weaknesses that can be attacked Outdated hardware which is no longer being supported and thus patches to fix security loopholes might not be available Lack of documentation will require that hardware administrators take longer to troubleshoot the hardware in the case of any issues as they might have to recollect the information from memory Let’s learn about software as part of enterprise architecture in the next screen.

2.60 Enterprise Architecture: Software

Software refers to operating systems, applications, drivers, utilities, middleware, application program interface, database management systems, and network operating systems. These are known to manage data, interface between systems, and provide a user interface to hardware and process transactions. Some of the risks associated with software include: Lack of patching leaves applications vulnerable to malware and misuse Lack of access control may allow unauthorized access Logic flaws will lead to the system not functioning correctly. Bugs coding errors of applications Sensitive information disclosure may lead to breach of confidentiality due to unauthorized access of information Let’s continue to learn about software as part of enterprise architecture in the next screen.

2.61 Enterprise Architecture: Software (contd)

Some of the other risks associated with software include poor input and output validation, loss of source code, and lack of version control. Here we will take a look at some risks associated with operating systems. This includes: Weak access controls Misconfiguration Unpatched vulnerabilities Uncontrolled changes Poorly written code (buffer overflows, etc.) Complexity and Lack of interoperability Let’s learn about applications as part of enterprise architecture in the next screen.

2.62 Knowledge Check

This question will help you recall the concepts you learned.

2.63 Enterprise Architecture: Applications

Applications are software developed to ease work and enhance functionality. There are certain risks associated with applications. These include: Lack of access control due to which users might not be appropriate authorization and authentication. Lack of data validation where the system will not check the integrity of data before it is processed. Poor coding practices such as lack of documentation and thus software might not be supported when the original developer is not available Exposure of sensitive data making it easy to breach confidentiality Lack of proper modification of data and thus losing the integrity of data Logic flaws which means data will not be processed correctly Let’s learn about applications as part of enterprise applications in the next screen.

2.64 Enterprise Architecture: Applications (contd.)

Some more risks associated with applications include: Software bugs. These are faults or errors in the software due to which it produces an incorrect result Lack of logs making it difficult to detect irregular activity Lack of version control posing a bigger risk of inability to control software changes and rolling back any changes made Loss of source code which lead to inability to update the software in house Lack of operability with other applications Back doors. These can be used by vendors to gain access and monitor the applications We shall learn about utilities as part of enterprise architecture in the next screen.

2.65 Enterprise Architecture: Utilities

Utilities are related to environmental controls and those that support the use of system resources. This includes: Some of the risks associated with types of environmental utilities are shown here. Click each type of utility to know more. Power interruptions HVAC Water Secure operational areas Click each utility to know more. Power interruptions: Various power interruptions, such as, loss of power surge, spikes, sags, brownouts, faults generators, insufficient capacity, and poor maintenance batteries. HVAC: HVAC related risks such as lack of maintenance, overheating, humidity problems, corrosion and condensation (high humidity), static (low humidity), and clogged filters. Water: Water related issues include loss of water for cooling systems and health and safety issues. Secure operational areas: Secure operational areas such as restricted access to server rooms and wiring closets and securing access to power supplies, generators, elevator shafts.   Utilities can also be used to refer to as the utilities and drivers supporting the use of system resources such as networks, printers, keyboards, and applications. Now that you have learned about risks associated with environmental utilities, we will now learn about risks associated with software utilities and drivers.

2.66 Enterprise Architecture: Software Utilities

Enterprise assets such as software utilities and drivers are prone to exposure to high level of risk as the visibility of unpatched software vulnerabilities is still weak. Software utilities and drivers have various risks associated. Some of them include: Unpatched drivers which will have loopholes that have already be exploited Out dated drivers that do not support inclusion of newer functionalities Unpatched vulnerabilities which can be exploited by attackers giving little to no time for the organization to respond Unavailability of drivers making it difficult for the application to function correctly and Insecure components that make the software prone to attacks Let’s learn about platforms as a component of enterprise architecture.

2.67 Knowledge Check

This question will help you recall the concepts you learned.

2.68 Enterprise Architecture: Platforms

Actually, platforms vary by organization. The platforms range from insourced to outsourced and from centralized to decentralized usage and multi-tiered platforms. The main types of platforms are single platform, three-tiered architecture, and multi-tiered platforms. Click each tab to know more about types of platforms. Organizations that are less complex may have all of their technology residing on a single platform such as the mainframe, while other companies use a variety of platforms to capture process and store information. Three-tiered architecture provides an interface between the underlying systems located on various servers and the user using a middleware. Multitier platforms such as a three-tiered infrastructure use middleware to interface between legacy systems and the front-end application. To reduce functionality and vulnerabilities at the client machine level many systems integrate with databases located on different networks, thin client infrastructures, and use of virtual environments. In the next screen, let us learn more about the network components of enterprise architecture.

2.69 Enterprise Architecture: Network Components

As you have learned the types of platforms, let’s see the network components of enterprise architecture. As you know, a network is an interconnection of devices such as switches, routers, cabling, repeaters, wireless access points firewalls, and gateways. Digital signals normally have higher quality than analog signals but require regeneration and extension using repeaters because of attenuation of signal quality. Network components are an important part of risk assessment because they are mostly targeted by an attacker.   We will continue to learn more about network components of enterprise architecture in the next screen.

2.70 Enterprise Architecture: Network Components (contd.)

Networks are used for many purposes. This includes: Transferring data between individuals Transferring data between applications Backing up data-storage area networks (SANS) Enabling communication between devices say for instance, Bluetooth Controlling and monitoring of remote equipment-supervisory control and data acquisition (SCADA) networks Let's continue with network components of enterprise architecture in the next screen.

2.71 Enterprise Architecture: Network Components

Well, now that you know the purpose of using network components, let’s learn about the network-based risks. In assessing network-based risk, the risk practitioner must examine the risk associated with the following: Protection of network equipment Network configuration and management, including the recognition of the criticality of network operations The use of layered defense in depth Suitable levels of redundancy Use of encryption for transmission of sensitive data Availability of bandwidth Let’s learn more how to assess the network-based risks in the next screen.

2.72 Enterprise Architecture: Network Components (contd.)

Alright, you will now learn about how to assess the network-based risks. The risk practitioner must also assess the network-based risks. This includes: Management of encryption key Use of certificates to support public key infrastructure (PKI) Tapping and eavesdropping on network communications Choice of network architecture Network architecture documentation and Cabling and network equipment damage We will discuss about cabling as a network component of enterprise architecture in the next screen.

2.73 Enterprise Architecture: Network Components - Cabling

Now that you have learned about network component of enterprise architecture, let’s move on to cabling. Cable and wireless technologies are used for network connection. The cable comes in the form of unshielded twisted pair or UTP, coaxial and fiber. The main types of cables are Category 5e (CAT5e) and category 6 (CAT6), and Category (CAT7) cables. Click each tab to know more about types of cable. Category 5e (CAT5e) and category 6 (CAT6) grade UTP cable is the cheapest option and relatively easy-to-use used to support fast Ethernet. Category (CAT7) cable is a shielded cable that reduced noise and cross talk for ultra-high speed Ethernet protects each pair of wires and the cable itself, thereby. This is available but not yet in use. Let us learn about concerns for the risk practitioner regarding cabling in the next screen.

2.74 Enterprise Architecture: Network Components - Cabling

What are the concerns for the risk practitioner regarding cabling? The concerns for the risk practitioner regarding cabling include: Improper terminations of cable on connectors Physical security of cabling Cable exceeding the approved length of the cable runs such as 55 meters for CAT6 and 100 meters for CAT5e Protection from damage to cabling using a conduit Use in an area of high radio frequency interference (RFI) thus may require shielding Use of cable that is not of suitable standard e.g., CAT3 Ensuring use of plenum-rated cable where required Improper or lack of cabling records Let’s learn about repeaters as part of network component of enterprise architecture in the next screen.

2.75 Knowledge Check

This question will help you recall the concepts you learned.

2.76 Enterprise Architecture: Network Components-Repeaters

Do you know what a repeater means? Well, a repeater is a transmission medium. It is important to ensure that enough repeaters are in use to provide an error-free signal. Some attributes of repeaters are listed here. Extend the length of a signal Filter out some noise or errors Click each tab to know more about the attribute of repeaters. Extend the length of a signal: Repeaters extend the length of a signal being transmitted over cable and wireless networks. As the signal traverses the network, it suffers from attenuation, and the repeater will be placed at a location to receive the input signal and regenerate the signal and send it on further. Filter out some noise or errors: The advantage of a repeater is that it can filter out some noise or errors that may be affecting traffic. The distance between them is based on the type of cabling or technology being used and the operational environment. Let’s learn about switches as a network component that is part of enterprise architecture in the next screen.

2.77 Enterprise Architecture: Network Components - Switches

Now that you have learned the attribute of repeaters, let’s learn why switches are used? Switches are used to connect devices together, and current switches perform the functions formerly provided by hubs and bridges (layer two). They forward packets to a destination, can perform routing functions (for a layer three switch), address translation and balancing (layer four), and perform load balancing by a layer seven switch. Switches are: Used to connect networks but also segment and divide networks through configurations such as a virtual LAN or VLAN, where different devices physically connected onto one switch may be set up to act as completely separate networks and They can be wired or wireless, small and inexpensive, or large and very expensive. Each organization must determine what equipment is suitable to meet its network requirements. In the next screen, we will learn about the risks associated with switches.

2.78 Enterprise Architecture Network: Components - Switches (contd.)

Now that you have learned about the uses of switches, let us understand the risks associated with switches. Basically, there are various risks associated with switches. Some of them are: Proper configuration of the switch Physically protecting the switch It is a single point of failure and Documentation Let’s discuss about routers as a network component that is part of the enterprise architecture in the next screen.

2.79 Enterprise Architecture: Network Components - Routers

Let’s now move on to the common attributes of routers. A router is a device that forwards data packets along networks. The common attributes of routers are:   A router connects multiple networks together and forward incoming packets in the direction of the destination IP address that is in the packet header. A router can vary in size, from a wireless router in a home that connects computers to the Internet, to large core routers that are responsible for the routing of high-speed Internet communications. The router builds a routing table using routing protocols, such as Border Gateway Protocol (the first routers were called gateways), and learns how best to direct traffic toward its destination.   In the next screen, we continue to learn about routers as a network component that is part of enterprise architecture.

2.80 Enterprise Architecture: Network Components - Routers (contd.)

Let’s now look at the labeling of the traffic in routers. Routers have labeling of the traffic. The label indicates that this packet should be processed quickly and not be held back by other packets waiting to be processed. The delay in processing is called latency, and this would severely affect the quality of some types of traffic such as voice over IP (VoIP). The label allows for provision of quality of service or QoS and class of service or CoS traffic management. QoS provides a guaranteed bandwidth for traffic volumes whereas CoS is used to grant priority to certain packets over others (for example, voice packets over regular data packets).   In the next screen, we will learn about some risk associated with a router.

2.81 Enterprise Architecture: Network Components - Routers (contd.)

Now that you have learned about the labeling of the traffic in routers, let us understand the risk associated with a router. Some of the risk associated with a router include: Physical security and thus the router can be irregularly accessed and be vandalized Improper configuration leading to vulnerabilities such as known ports being opened and default passwords being retained which are widely published. Unpatched systems which means known and existing vulnerabilities in the router can be exploited. Use of weak protocols (RIPvl) which can easily be breached. Software bugs which will lead to the router behaving abnormally when it experiences an unexpected condition. We shall learn about firewall as a network component that is part of enterprise architecture in the next screen.

2.82 Enterprise Architecture: Network Components-Firewalls

Let’s now move on to firewalls. Firewall is a boundary between two or more networks that forms a barrier between a secure and an open environment. The firewall related tasks of a risk practitioner include: The risk practitioner must use firewalls to control both outgoing and incoming traffic firewalls. Review and backup firewall configurations on a regular basis firewall configurations on a regular basis so that rules are in the correct order and documented. Firewall configuration changes should be subject to the change management process of the organization. Review of firewall logs regularly to identify suspicious events. Always ensure that the risk practitioner or any other staff managing the firewall is well trained. In the next screen, we will learn about types of firewall.

2.83 Knowledge Check

This question will help you recall the concepts you learned.

2.84 Enterprise Architecture: Network Components-Firewalls

As you know, there are several types of firewalls. The types of firewalls include first generation, second generation, third generation, and next generation. Click on each type to know more. First generation: A simple packet-filtering router that examines individual packets and enforces rules based on addresses, protocols and ports. Second generation: Keeps track of all connections in a state table. This allows it to enforce rules based on packets in the context of the communications session. Third generation: Operates at layer seven (the application layer) and is able to examine the actual protocol being used for communications, such as Hypertext Transfer Protocol (HTTP). These firewalls are much more sensitive to suspicious activity related to the content of the message itself, not just the address information. Next generation: Sometimes called deep packet inspection—is an enhancement to third generation firewalls and brings in the functionality of an intrusion prevention system (IPS) and will often inspect Secure Sockets Layer (SSL) or Secure Shell (SSH) connections. Let's learn about proxy as a network component that is part of enterprise architecture in the next screen.

2.85 Enterprise Architecture: Network Components-Proxy

Now that you have learned about firewalls, let’s take a look at proxy and its uses. Proxy is a device that acts as an intermediary between two parties communicating. It acts on the party on each side of the communication. A gateway is a type of proxy that controls traffic through a gate or security perimeter.   Use of proxy helps in filtering and examining suspicious activity by protecting internal resources. It then takes appropriate action against any unacceptable event. We will look at domain name system in the next screen.

2.86 Enterprise Architecture: Network Components-Domain Name System

After learning about proxy and its uses, let’s learn certain aspects of DNS. The domain name system or DNS is a mechanism that plays an important role in the operation of the Internet. The DNS provides a simple cross-reference that is used to associate a normal name with the IP address used by network devices. The IP address is a logical address given to a web site based on the addresses allocated to the Internet service provider (ISP). DNS is a tree structure that resolves the addresses so that a network device that receives a request from a person entering a web name for example www.isaca.org will be able to look up the IPv4 address and then route the request properly through the network. In the next screen, we will learn about wireless access points as a network component that forms part of the enterprise architecture.

2.87 Enterprise Architecture: Network Components-Wireless Access Points

As you know, wireless devices offer a level of flexibility and ease of use not possible with traditional cable-based networks. Users can move around the office and log in from multiple locations without requiring a network cable and port. The main risks that can be associated with wireless networks include: Wrong placement of access points Threat of unauthorized access and Rogue wireless access points installation Click each tab to know more about the type of risk. Placement of the wireless access points in a location that is not subject to interference from other devices or near a window that would broadcast a strong signal outside of the organization’s facilities is also important. The threat of unauthorized people being able to log in, this requires segmenting the wireless access into a separate network and implementing a strong password requirement for network access The installation of rogue wireless access points on the network is also a serious threat because a rogue device may permit a person to access the network directly without having to connect through a secure device or to bypass firewalls or other layers of defense. We will learn about other network devices that are part of the enterprise architecture in the next screen.

2.88 Enterprise Architecture: Network Components-Other Network Devices

Well, there are many other types of networking equipment and protocols used for network communications. It is important to ensure proper functioning of the various network devices considering the following aspects: The proper configuration of these devices is a critical part of secure communications and network reliability and stability. Unpatched systems and protocols is a common problem related to network security such as the network time protocol or NTP based attacks of late 2013 that resulted from many organizations having unpatched NTP implementations. Let's learn about network architecture in the next screen.

2.89 Enterprise Architecture: Network Architecture

After learning about types of networking equipment, let’s understand about network architectures. The network architectures in use today range from bus networks to high-speed fiber backbones. The choice of network architecture is based on: Distance: Such as local area network or LAN versus wide area networks or WAN. Number of devices: (say for instance, an old peer-to-peer network could only handle 8 to 12 devices). Communications requirements of the network, for example speed, confidentiality, and reliability. We will continue to learn more about network architecture in the next screen.

2.90 Enterprise Architecture: Network Architecture

Since any network can fail then the risk practitioner must consider the impact of any failure and the ways that a failure can be mitigated. The types of network topologies include Bus network topology, Tree network topology, Ring network topology, Star network topology, and mesh network topology. Click each tab to know more about types of topologies. Bus network topology which connects every device onto one bus or communications path. The risk is that a cut cable may result in total network failure, and it is relatively easy to sniff a bus network. This is one reason why an encrypted. VPN must be used on cable modem Internet access. Tree network topology is a series of star networks arranged with branches to other star networks in a tree-type structure. A cut link between the branches of the tree could cause isolation of that branch, but this type of network is very scalable. Ring network topology is used in backbones and areas where reliable high-speed communications and fault tolerance is desired. A ring connects every device into one ring and passes traffic from device to device around the ring. And its excellent for busy networks where a switched Ethernet would be inefficient and lead to too many collisions or traffic congestion. However, a ring is more expensive that most other technologies. Star network topology where every device is connected to a central switch which is more difficult to eavesdrop on or sniff communications though the central switch is a single point of failure. A mesh network topology is used where high availability is required, the Internet itself is a partial mesh and was built to survive massive failures of any one part of the network and still allow communications over the rest of the Internet. Cost and scalability are the main risk associated with a mesh network i.e. the difficulty of adding new components to the network Let's continue to learn more about network architecture in the next screen.

2.91 Enterprise Architecture: Network Architecture (contd.)

Alright, let’s more about other network architecture. Other network architectures that exist include: Wide Area Network- computer network connecting different remote locations that may range from short distances, such as a floor or building, to extremely long transmissions that encompass a large region or several countries. Local Area Network- communication network that serves several users within a specified geographic area, such as a building Packet-switching Networks- allows a communications network to be shared by multiple organizations, and are fairly resistant to total network failure since they are a type of partial mesh Microwave- a line-of-sight technology where the sending and receiving stations need a clear line of sight between each other. Optical- communication based on laser technology, transmitting fairly high-speed communications using a laser transceiver Satellite- allows communications from remote areas where it was not previously possible to provide other forms of communications Leased lines- lines leased/rented from a telecommunications carrier and is provided for the sole use of the organization as a private network Extranet- accessible from outside of the organization and is used for trusted communications, such as communicating with business partners and Demilitarized Zone- the area of the network that is accessible to outsiders through the Internet is isolated into a demilitarized zone(DMZ) A few questions will be presented in the following screens. 

2.92 Knowledge Check

This question will help you recall the concepts you learned.

2.93 Quiz

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

2.94 Summary

Here is a quick recap of what we have learned in this domain: Risk scenarios are developed during risk identification and used to identify and describe potential risk events. Quantitative risk assessment is often based on the calculation of the impact of a single risk event and the event cost. Risk ranking is used to direct the risk response effort after compiling the results of risk assessment Current state refers to the condition of the program at a point in time, so the risk assessment is only valid at the time the risk state is measured.

2.95 Summary (contd.)

Threat modeling is done by mapping the potential methods, approaches, steps and techniques used by an adversary to perpetrate an attack. The decision to outsource technology functions should be carefully considered from a risk and regulatory perspective The organization should not lose sight of the business risk involved when deploying new unproven technologies. Enterprise architecture helps generate a view of the current state of IT, establish a vision for the future and formulate a strategy to get there.

2.96 Conclusion

This concludes the domain on Risk Assessment. The next domain will focus on Risk Response.

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

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

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*

By proceeding, you agree to our Terms of Use and Privacy Policy