Information Security Risk Management Assignment
For this exercise, read the provided case study about AcmeHealth, and re-rate the risk exposure for each finding related to the following assets:
1. Code Repository
2. QA Server
3. Production Application Server
Assume that additional information has been provided below by the Subject Matter Experts during the qualification process. Be sure to note any findings where you are changing your original assessment of the risk level and why. Review the provided example as a guideline.
Like the last assignment, you will need to assess the severity of each violation and also the likelihood that it would cause a breach of security.
Use the severity and likelihood scales from Appendix B in the book (Tables 6.11 and 6.12) to evaluate each finding. A mapping table is provided (Figure 6.2) to calculate the Risk Exposure value for each severity/likelihood pair without taking sensitivity into account for now.
If you don't understand the technical details of any of the findings, please post questions to the Discussion Forum and ask the instructor to clarify.
You can turn in the assignment electronically through Blackboard.
Review each finding again, and assume that the following answers have been provided by the subject matter experts for that resource. Use these answers to provide a more informed assessment of the risk below:
Table 1 - Finding Qualification Updates
|
#
|
Resource
|
Finding
|
Qualification Answers
|
|
1
|
Code Repository
|
Resource administrators don't verify the integrity of the information resource patches through such means as comparisons of cryptographic ...
|
- All updates are obtained directly from the vendor's site (IBM in this case for the AIX servers)
- All patches are thoroughly tested in DEV, and QA environments before being installed on the Code Repository Server.
|
|
2
|
Code Repository
|
Network connections from the offshore developers' workstations to the code repository server are not encrypted.
|
- Sessions to the server never expire
- Password complexity is not enforced by the server
- Connections from the offshore network to AcmeHealth's network is across a VPN
- Some scripts containing passwords are stored in the code repository
|
|
3
|
QA Server
|
Client data is copied from production servers to this server regularly for QA testing.
|
- Data is not stored encrypted on the QA Server
- Developers have privileged access to the database in QA
- The QA Server allows connections from the Internet to simulate client traffic and performance testing
|
|
4
|
Production Application Server
|
No one notifies the Help Desk of terminations for support personnel in order to ensure that their access is disabled.
|
- Administrative interfaces can only be accessed from the internal network
- Server audit logs are retained on a separate SEIM infrastructure
- Accounts that aren't used for 180 days are automatically disabled
- Both the application and databases servers are behind firewalls
|
Please note that you are reassessing these findings. Finding 1 is provided as an example.
Record your new severity and likelihood ratings and justifications below, being sure to note if the overall risk rating for the finding has changed now that you have more information. An example for the first finding has been provided:
Finding 1:
Severity: High Justification: The potential severity of this risk has not changed. If malicious code is allowed onto the system through an application patch, this could compromise that application potentially allowing backdoor access to attackers or allow sensitive data to be sent from the application to the attackers. The malicious code may also cause the application to be unstable, causing it to crash periodically.
Likelihood: Negligible Justification: The potential likelihood of this risk has been lowered from Low to Negligible, because patches are always obtained from a credible and trusted source (the vendor is IBM in one case), and all patches are tested thoroughly in both the Development and QA environments before being applied to more sensitive Code Repository Server. Although it is possible for attackers to place fake application patch updates on sites that look legitimate, for most commercial software this would be more difficult and the attacker would have to be very motivated and have a high level of skill. Even if the attacker was able to compromise the vendor's server, the malicious patch would likely be discovered during DEV or QA testing before it reached the Code Repository server.
Risk: Low Justification: The overall risk of system or data compromise through a maliciously crafted patch update has not changed. It is still very unlikely that a malicious update would be applied to the Code Repository server without being detected first. If one were to take it past the several layers of control, this could put the server in jeopardy of being controlled by an outside attacker. In this case, an attacker could modify the code to put backdoors into the production application, or more likely the proprietary code could be stolen.
Finding 2:
Severity: ________________ Justification: ______________
Likelihood: ________________ Justification: _____________
Risk: ________________ Justification: _________________
Finding 3:
Severity: ________________ Justification: ______________
Likelihood: ________________ Justification: _____________
Risk: ________________ Justification: _________________
Finding 4:
Severity: ________________ Justification: ______________
Likelihood: ________________ Justification: _____________
Risk: ________________ Justification: _________________