There is a major development project going on with over 100 developers. It is being performed on a cluster of 80 Linux and Solaris servers and workstations and a distributed file system over a large LAN. There are 10 servers doing builds and several used for file systems. The primary application development and testing tool in use is the Micro Focus Application Lifecycle Management (ALM) product. This network also supports a web server, email server and provides the working home directories for all desktop systems. Finally, some of the Linux and Solaris servers support Oracle databases. There is also a Windows domain that is used by non-IT personnel (HR, Finance, etc.). This domain has a few servers running Microsoft SQL Server.

The Risk Manager is responsible for reviewing and maintaining the Global Security Policy (GSP) and ensuring that all controls are being performed. In addition, any exceptions should have a Risk Acceptance Form (RAF) associated with it, along with the required approvals. Perform a risk management assessment and a risk mitigation plan for this computing and software tools infrastructure. Identify risks, estimate risk probability and impact, identify the potential for risk mitigation, and identify potential risk responses.

Areas of concern:

Admin access to the Windows and Unix systems

Password configurations may not be set properly for any of the operating environments

Unauthorized code changes

Backup tapes are suspect. They should be tested quarterly.

An alternate power source may not be reliable if the main power fails. These should be tested monthly.

Improper database access

Context:

The project is under delivery pressure and people are already working 10-12 hours a day.

The development and production environments may not be as separated as they should be, especially within ALM.

There has been quite a bit of turnover. There are now two very junior systems administrators. One of them possesses decent knowledge of Windows, while the other claims to be a Unix expert. They both know just enough about databases to be dangerous.

Deliverables

Layout and format. The layout and format for the mini-project are defined in the Risk Register document template.

Perform risk assessment on this system and suggest mitigation plan.

Estimate the probability of each event occurring and the impact.

Executive summary. an assessment of the computing environment and areas of concern. Document the most serious risks. Describe the areas of most concern based on the information above and the probable events that might occur. risk audit and discuss the potential problems. You should add a summary assessment on the current state of the project vs. the ideal state and make recommendations.

Risk Register Use the Risk Register template to define the risks for this project. Copy and paste the table in the template in order to have a risk register entry for each identified risk. The items in the risk register entry include:

Risk number. A unique number assigned to each risk register entry. Use any suitable numeric or alphanumeric format.

Risk rating. Use the CV@@ 3.1 calculator to determine the risk scores.

The calculator can be accessed here: https://www.first.org/cvss/calculator/3.1

Risk owner. The owner for the risk, the project team member charged with monitoring the risk and implementing the risk response plan should the risk event occur. It is not necessary to enter a person's namethe owner's role in the project will suffice. Description. A brief description of the risk.

Project objectives impacted. Project objectivecost, time, scope, or qualityimpacted by this risk. If the risk impacts more than one objective, provide a risk register entry for only the highest-impact objective.

Risk probability. The probability, pR that the risk event will occur. 0.0 pR 1.0. For example, if the probability is 1 in 5, then note it as 0.20.

Risk impact. The impact value of the risk. Estimates are ok here.

Potential triggers or precursors. List any identified triggers or precursors for the risk event.

Potential mitigation. List any ways that the likelihood of the risk can be reduced or its impact on the project reduced.

Potential responses. List any risk event responses identified. These need not be detailed risk response plans, but should be a description of what would be done should the risk response event occur.

Root causes. If it is possible to identify root causes for the risk, list them here, each with a brief description.

How many risks should identify? At least ten major risks across all environments.