risk 2

Question 1

Different Risk Management Perspectives

Answer 1

General vis-a-vis specialized risk management
Organization-centric risk management
SE Project Centric risk management
Application-centric risk management
Supply chain risk management
Risk management in emerging technologies
Risk management through IT auditing and checklists.
Business continuity management as a risk management tool.

Question 2

General vis-a-vis specialized risk management

Answer 2

Risk management is a pervasive activity inherent in all environments.
- General Risk Management covers basic concepts that are sufficiently generic to apply to various contexts ex. ISO31000
- Specialized Risk Management can be seen as extending, or building upon general risk management, and covers specific environments, ex. ISO/IEC27005

Question 3

Organization Centric Risk Management

Answer 3

Primarily aims to address risks that are pertinent to the organization as a whole. For example, the generation of low quality code might not be a significant risk for the organization but it would have been on a project basis. Wider scope of risk.

Question 4

SE Project Centric Risk Management

Answer 4

Potential Conflicts between an SE project and the context framing it: Context framing is very important in project centric risk management. It is useful to consider that the interests relating to a SE project may not be aligned with other interests in the organization. If the SE project is too innovative it may have to be shut down, sold to another org etc.

Question 5

Application-Centric Risk Management

Answer 5

Application centric risks tend to be more technical, such as:
- Insecure coding (new version typically every 3-4 years)
- The use of untrustworthy cloud services
- Application running on unpatched operating systems
- Application running with insecure computer network environments
- Lack of rigor in testing
- Lack of documentation
- Lack of configuration management

Question 6

Supply Chain Risk Management

Answer 6

Examples of Supply Chain Risk:
- Over or underestimating the need for subcontractors
- The choice of the wrong subcontractor/s due to:
- Lack of competence
- Lack of resources
- The jurisdiction in which they operate
- Exclusion of important clauses from the engagement contract, relating to:
- Data protection
- Confidentiality - NDA
- Right to audit the subcontractor
- Need to have an ISMS in place

Question 7

Risk Management in Emerging Technologies

Answer 7

Some examples of past emergent technologies include IOT, 3D printing, the internet, quantum computing and low code technology.

Question 8

There are five attributes that feature in the emergence of a novel technology:

Answer 8

Radical Novelty
Relatively fast growth
Coherence
Prominent Impact
Uncertainty and ambiguity

Question 9

Radical Novelty

Answer 9

• Fulfilling a given function using a different basic principle to what was used before.
• Publications and patents are limited in assessing radical novelty contemporarily.
• In contrast, news articles etc are valuable sources that provide good insight into whether a technology is viewed as radically novel.
• These documents may also provide a basic understanding of the principles underpinning the examined technology.

Question 10

Relatively Fast Growth

Answer 10

Especially when compared to non-emergent technologies, relatively fast growth rates. Growth rates may be revealed from the analysis of funding data, big data and altmetrics. Most studies assume rapid growth is an essential condition of emergence.

Question 11

Coherence

Answer 11

Coherence and its persistence over time distinguish technologies that have acquired a certain identity and momentum and distinguish from those still in a state of flux and thus not yet emerging. It may be detected by examining the scientific discourse around a given emergent technology.

Question 12

Prominent Impact

Answer 12

Emerging technologies exert a prominent impact on specific domains or more broadly in the socio-economic system. They do so by changing the composition of actors’ institutions, patterns of interactions among those and the associated processes for the production of knowledge.

Question 13

Uncertainty and Ambiguity

Answer 13

Emerging technologies are characterized by uncertainty in their possible outcomes and uses, both can be utilized to identify and manage SE project risks as the controls used in control-based audits are typically based on past experience, and risk-based audits are based on the risks identified by the auditor.

Question 14

Risk Management through IT Auditing (and checklists)

Answer 14

Two approaches are used for the performance of IT audits; control-based audits and risk-based audits. Both can be utilized to identify and manage SE project risks because the controls used in control-based audits are typically based on past experience, and risk-based audits are based on the risks identified by the auditor.

Question 15

Control-Based Audits

Answer 15

These are the characteristics of control-based audits:
- Audit starts with a list of expected controls based on best practice
- The auditor evaluates the controls
- The auditor reports on inadequacies relating to the controls
The controls would be based on existing checklists, standards and guidelines ex. ISO/IEC27001. Therefore, the controls are based on previous experience about the risks faced by organizations. Control based audits are generally considered an outdated approach

Question 16

Risk-Based Audits

Answer 16

Step 1: Establish the Terms of Reference (ToR) - Scope, Objectives, Authority
Step 2: Identify the risks - Analyze business area and identify critical areas. What could cause loss? Use information from previous audits and risk assessments.

Step 3: Identify Controls - to be used as Audit Controls ex. Using an enterprise wide risk matrix (EWRM).

Step 4: Create Risk and Control (RaC) matrix columns for: risk description, expected controls, actual controls found (empty), issues (empty).

Step 5: Investigate Controls
Populate the RaC, by looking at the controls
Compliance tests
Substantive tests i.e are controls in place

Step 6: Create Issue Log (list the identified issues)

Step 7: Report; write the audit report and submit to the business unit being audited, the business unit responds and then the auditor responds, may need more than one cycle.

Step 8: Auditor monitors outstanding issues over time, including regular revision. A large number of outstanding issues may trigger further audits.

Question 17

Business Continuity Management as a Risk Management Tool

Answer 17

IT disaster recovery (ITDR) is considered a subset of DR and IT BCM
IT business continuity management (IT BCM) is a subset of BCM.

Question 18

Recovery Time Objective (RTO)

Answer 18

The maximum acceptable time that an application, computer, network or system can be down after an unexpected disaster, failure or comparable event takes place.

Question 19

Recovery Point Objective (RPO)

Answer 19

The maximum amount of data loss, measured in time, for the critical business data.

Question 20

BCM, IT BCM, DR, IT DR, Operational Resilience & SE Project Management

Answer 20

These notions relate to SE project management as software development organizations need to be prepared for distribution while in the process of developing systems.
The design of IT systems (incl. Hardware and software) needs to be based on considerations of the client’s data and service availability requirements ex. Shall we use cloud services or alternatives?

Question 21

Top 10 Risks according to OWASP:

Answer 21

Broken access control
Cryptographic failures
Injection
Insecure Design
Security misconfiguration
Vulnerability and outdated components
Identification and authentication failures
Software and data integrity failures
Security logging and monitoring failures
Server side request forgery.

Question 22

Distinguish Characteristics between different risk management contexts

Answer 22

Language Used: there will often be variations in terms and concepts used in different risk management contexts ex. The ideas of thread and vulnerability are important to infosec but not in financial risk management.

Processes Adopted: In certain areas, ex. Infosec where things change quickly, it may be more difficult to adopt a quantitative approach because of lack of historical data.

Levels of formality: Ex. Software testing in the context of a social platform can be less formal than in the context of avionics. Testing contributes to risk management.

Question 23

Find the risk relating to an SE project from the perspectives

Answer 23

The organization’s general risk management function
The operations of the company/s involved in development
The security of the software being developed
The legal liabilities relating to the specialized software being developed ex. Financial trading software.

Question 24

A project manager responsible for SE-Project centric risk management needs to consider;

Answer 24

The context that frames the projects (economic, social etc.)
The organization’s own risk management structures

Question 25

Examples of wider risk management structures

Answer 25

An organization-wide risk management function
An organization-wide Information Security Management System (ISMS)
An organization-wide Quality Management System (QMS)

Question 26

Where risk management structures exist, the project manager may choose or be forced to use them by…

Answer 26

By defining an SE project-centric risk management process in line with a central policy

By reporting project risks that exceed a certain threshold to specific audiences

By utilizing the company’s existing Business Continuity Management, Incident management and/or training and awareness programs.

By seeking input from the legal, governance risk and compliance and Infosec departments.

Question 27

How do existing risk management structures support a SE project

Answer 27

By avoiding issues like:
- Employing untrustworthy or incompetent developers.
- Using non-fictitious test data that exposes the organization to legal risks ex. Privacy
- Adopting low quality software development and/or testing techniques.
- Developing or deploying software in insecure environments such as compromised physical layer, networking layer or system software layer.

Question 28

By implementing an effective ISMS the organization can avoid issues such as

Answer 28

Selecting low quality cloud service providers that are incompetent or unsupported by popular certifications

Relying on subcontractors having limited capabilities ex. A team in Ukraine, Subpar subcontractors etc.

Question 29

SE Project Centric vis a vis application centric risk management

Answer 29

Project centric risks may conflict with application centric risks, ex.
- It may be necessary to accept a lower level of coding (application centric risk) to meet project deadlines (address a project centric risk).
- May be necessary to address coding errors (application centric risk) despite delays (project centric risk).

Question 30

Examples of Project Centric risks include

Answer 30

poorly trained managers, too many projects at the same time, lack of funding, inconsistency in approach, lack of strategic alignment, lack of appropriate software.

Question 31

Examples of SE project planning misjudgments include

Answer 31

over optimistic schedules, stakeholder unavailability, resource unavailability, weak monitoring, letting personal views affect objectivity, staff augmentation (especially on a late project).

Question 32

Sources of Software Project Risks

Answer 32

Generic: Applicable and common to all types of SE projects, but might provide different levels of accuracy across different project types.

Specific: Applicable and more appropriate to specific types of projects, but will require closer involvement by project team members.

Question 33

Main risk categories to consider (Software Project Risks)

Answer 33

The nature of application being built
Staff morale, skills, experience, motivation and availability
Project culture and procedure and/or methods
Hardware, platform and OS requirements
Implementation and changeover issues
Third-party dependency
Real world requirement shifts

Question 34

Traditional SE Risks include

Answer 34

personnel shortfalls, unrealistic schedules and budgets, developing the wrong functions, developing the wrong user interface, gold plating, continuing steam of requirements, shortfalls in externally furnished tasks, real time performance shortfalls and straining computer science capabilities.

Question 35

Risk classification

Answer 35

several taxonomies exist, which aim to list and categorize different types of risk.

Question 36

Estimation Inaccuracies

Answer 36

Estimation methods lack accuracy and it is expected to.

Question 37

Why do we love estimation methods

Answer 37

because they are an indispensable tool for forecasting, they can work at many levels of abstraction so they are refinable and they can be rendered more accurate by incorporating experience and historical data.

Question 38

We do we hate estimation methods

Answer 38

because they can be based on subjective data at times, they can take on an idealistic outlook, and they can be frustrating in their data requirements.