Breaking News

Sunday, August 9, 2015

ISM unit 1 question bank answers 6-10

QUESTION NUMBER 6-10

6. Explain generic risk model in detail.

Risk models define the risk factors to be assessed and the relationships among those factors.Risk factors are characteristics used in risk models as inputs to determining levels of risk in risk assessments. Risk factors are also used extensively in risk communications to highlight what strongly affects the levels of risk in particular situations, circumstances, or contexts. Typical risk factors include threat, vulnerability, impact, likelihood, and predisposing condition.

Threats 
A threat is any circumstance or event with the potential to adversely impact organizational operations and assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service.Threat events are caused by threat sources.

Risk models differ in the degree of detail and complexity with which threat events are identified. When threat events are identified with great specificity, threat scenarios can be modeled, developed, and analyzed

Threat shifting 
is the response of adversaries to perceived safeguards and/or countermeasures (i.e., security controls), in which adversaries change some characteristic of their intent/targeting in order to avoid and/or overcome those safeguards/countermeasures. Threat shifting can occur in one or more domains including: (i) the time domain (ii) the target domain (iii) the resource domain or (iv) the attack planning/attack method domain

Vulnerabilities and Predisposing Conditions 
A vulnerability is a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source.Most information system A predisposing condition is a condition that exists within an organization, a mission or business process, enterprise architecture, information system, or environment of operation, which affects (i.e., increases or decreases) the likelihood that threat events, once initiated, result in adverse impacts to organizational operations and assets, individuals. vulnerabilities can be associated with security controls that either have not been applied (either intentionally or unintentionally), or have been applied, but retain some weakness.
Vulnerabilities are not identified only within information systems. Viewing information systems in a broader context, vulnerabilities can be found in organizational governance structures

Likelihood 
The likelihood of occurrence is a weighted risk factor based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability (or set of vulnerabilities). The likelihood risk factor combines an estimate of the likelihood that the threat event will be initiated with an estimate of the likelihood of impact (i.e., the likelihood that the threat event results in adverse impacts). For adversarial threats, an assessment of likelihood of occurrence is typically based on: (i) adversary intent; (ii) adversary capability; and (iii) adversary targeting.

Impact
The level of impact from a threat event is the magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. Such harm can be experienced by a variety of organizational and nonorganizational stakeholders including

Risk:- 
risk is a function of the likelihood of a threat event’s occurrence and potential adverse impact should the event occur.It also accommodates relationships among impacts (e.g., loss of current or future mission/business effectiveness due to the loss of data confidentiality; loss of confidence in critical information due to loss of data or system integrity; or unavailability or degradation of information or information systems). This broad definition also allows risk to be represented as a single value or as a vector (i.e., multiple values),in which different types of impacts are assessed separately.


7. What are the key characteristics of OCTAVE approach?

OCTAVE is self directed, requiring an organization to manage the evaluation process and make information-protection decisions. An interdisciplinary team, called the analysis team, leads the evaluation. The team includes people from both the business units and the IT department, because both perspectives are important when characterizing the global, organizational view of information security risk.
The Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE®) approach is one such framework that enables organisations to understand, assess and address their information security risks from the organisation’s perspective. The OCTAVE approach was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University to address the information security compliance challenges faced by the US Department of Defense (DoD). OCTAVE is self directed, requiring an organization to manage the evaluation process and make information-protection decisions. OCTAVE is an asset-driven evaluation approach. Analysis teams
• identify information-related assets (e.g., information and systems) that are important to the organization
• focus risk analysis activities on those assets judged to be most critical to the organization
• consider the relationships among critical assets, the threats to those assets, and vulnerabilities (both organizational and technological) that can expose assets to threats
 • evaluate risks in an operational context - how they are used to conduct an organization’s business and how those assets are at risk due to security threats
• create a practice-based protection strategy for organizational improvement as well as risk mitigation plans to reduce the risk to the organization’s critical assets


8. Explain reactive approach to Risk management with proper diagram.

The reactive approach may be an effective response to the security risks that have already occurred through creating security incidents. The analysis of the causes of producing security incidents could help the organization to prevent their repetition and be prepared for any possible problems. Companies that respond to security incidents in a calm and rational way, meanwhile they determine the causes that have allowed the incidents to occur, will be able to respond in a shorter time to similar problems arising. There are six steps that an organization should take into consideration when the reactive approach is applied:

1. Protect human life and people's safety. 
This should always be your first priority. For example, if affected computers include life support systems, shutting them off may not be an option; perhaps you could logically isolate the systems on the network by reconfiguring routers and switches without disrupting their ability to help patients.

2. Contain the damage. 
Containing the harm that the attack caused helps to limit additional damage. Protect important data, software, and hardware quickly. Minimizing disruption of computing resources is an important consideration, but keeping systems up during an attack may result in greater and more widespread problems in the long run. For example, if you contract a worm in your environment, you could try to limit the damage by disconnecting servers from the network. However, sometimes disconnecting servers can cause more harm than good. Use your best judgment and your knowledge of your own network and systems to make this determination. If you determine that there will be no adverse effects, or that they would be outweighed by the positive benefits of activity, containment should begin as quickly as possible during a security incident by disconnecting from the network the systems known to be affected. If you cannot contain the damage by isolating the servers, ensure that you actively monitor the attacker’s actions in order to be able to remedy the damage as soon as possible. And in any event, ensure that all log files are saved before shutting off any server, in order to preserve the information contained in those files as evidence if you (or your lawyers) need it later.

3. Assess the damage. 
Immediately make a duplicate of the hard disks in any servers that were attacked and put those aside for forensic use later. Then assess the damage. You should begin to determine the extent of the damage that the attack caused as soon as possible, right after you contain the situation and duplicate the hard disks. This is important so that you can restore the organization's operations as soon as possible while preserving a copy of the hard disks for investigative purposes. If it is not possible to assess the damage in a timely manner, you should implement a contingency plan so that normal business operations and productivity can continue. It is at this point that organizations may want to engage law enforcement regarding the incident; however, you should establish and maintain working relationships with law enforcement agencies that have jurisdiction over your organization's business before an incident occurs so that when a serious problem arises you know whom to contact and how to work with them. You should also advise your company’s legal department immediately, so that they can determine whether a civil lawsuit can be brought against anyone as a result of the damage.

4. Determine the cause of the damage. 
In order to ascertain the origin of the assault, it is necessary to understand the resources at which the attack was aimed and what vulnerabilities were exploited to gain access or disrupt services. Review the system configuration, patch level, system logs, audit logs, and audit trails on both the systems that were directly affected as well as network devices that route traffic to them. These reviews often help you to discover where the attack originated in the system and what other resources were affected. You should conduct this activity on the computer systems in place and not on the backed up drives created in step 3. Those drives must be preserved intact for forensic purposes so that law enforcement or your lawyers can use them to trace the perpetrators of the attack and bring them to justice. If you need to create a backup for testing purposes to determine the cause of the damage, create a second backup from your original system and leave the drives created in step 3 unused.

5. Repair the damage. 
In most cases, it is very important that the damage be repaired as quickly as possible to restore normal business operations and recover data lost during the attack. The organization's business continuity plans and procedures should cover the restoration strategy. The incident response team should also be available to handle the restore and recovery process or to provide guidance on the process to the responsible team. During recovery, contingency procedures are executed to limit the spread of the damage and isolate it. Before returning repaired systems to service be careful that they are not reinfected immediately by ensuring that you have mitigated whatever vulnerabilities were exploited during the incident.

6. Review response and update policies. 
After the documentation and recovery phases are complete, you should review the process thoroughly. Determine with your team the steps that were executed successfully and what mistakes were made. In almost all cases, you will find that your processes need to be modified to allow you to handle incidents better in the future. You will inevitably find weaknesses in your incident response plan. This is the point of this after-the-fact exercise—you are looking for opportunities for improvement. Any flaws should prompt another round of the incident-response planning process so that you can handle future incidents more smoothly.


9. Explain proactive approach to risk management. What are the benefits over reactive approach?

Proactive security risk management has many advantages over a reactive approach. Instead of waiting for bad things to happen and then responding to them afterwards, you minimize the possibility of the bad things ever occurring in the first place. You make plans to protect your organization's important assets by implementing controls that reduce the risk of vulnerabilities being exploited by malicious software, attackers, or accidental misuse. An analogy may help to illustrate this idea. Influenza is a deadly respiratory disease that infects millions of people in the United States alone each year. Of those, over 100,000 must be treated in hospitals, and about 36,000 die. You could choose to deal with the threat of the disease by waiting to see if you get infected and then taking medicine to treat the symptoms if you do become ill. Alternatively, you could choose to get vaccinated before the influenza season begins.

Organizations should not, of course, completely forsake incident response. An effective proactive approach can help organizations to significantly reduce the number of security incidents that arise in the future, but it is not likely that such problems will completely disappear. Therefore, organizations should continue to improve their incident response processes while simultaneously developing long-term proactive approaches.

Each of the security risk management methodologies shares some common high-level procedures:
1. Identify business assets.
2. Determine what damage an attack against an asset could cause to the organization.
3. Identify the security vulnerabilities that the attack could exploit.
4. Determine how to minimize the risk of attack by implementing appropriate controls.

Proactive security risk management has many advantages over a reactive approach. Instead of waiting for bad things to happen and then responding to them afterwards, you minimize the possibility of the bad things ever occurring in the first place. You make plans to protect your organization's important assets by implementing controls that reduce the risk of vulnerabilities being exploited by malicious software, attackers, or accidental misuse.


10. Write a short note on OCTAVE.

The Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE®) approach is one such framework that enables organizations to understand, assess and address their information security risks from the organization’s perspective. OCTAVE is not a product, rather it is a process driven methodology to identify, priorities and manage information security risks. It is intended to help organizations :
• Develop qualitative risk evaluation criteria based on operational risk tolerances
• Identify assets that are critical to the mission of the organization.
• Identify vulnerabilities and threats to the critical assets
• Determine and evaluate potential consequences to the organization if threats are realized
• Initiate corrective actions to mitigate risks and create practice-based protection strategy

For an organization looking to understand its information security needs, OCTAVE is a riskbased strategic assessment and planning technique for security. OCTAVE is self-directed, meaning that people from an organization assume responsibility for setting the organization’s security strategy. The technique leverages people’s knowledge of their organization’s security-related practices and processes to capture the current state of security practice within the organization. Risks to the most critical assets are used to prioritize areas of improvement and set the security strategy for the organization
Unlike the typical technology-focused assessment, which is targeted at technological risk and focused on tactical issues, OCTAVE is targeted at organizational risk and focused on strategic, practice-related issues. It is a flexible evaluation that can be tailored for most organizations. When applying OCTAVE, a small team of people from the operational (or business) units and the information technology (IT) department work together to address the security needs of the organization

The OCTAVE approach is driven by two of the aspects: operational risk and security practices. Technology is examined only in relation to security practices, enabling an organization to refine the view of its current security practices. By using the OCTAVE approach, an organization makes information-protection decisions based on risks to the confidentiality, integrity, and availability of critical information-related assets. All aspects of risk (assets, threats, vulnerabilities, and organizational impact) are factored into decision making, enabling an organization to match a practice-based protection strategy to its security risks. Table 1 summarizes key differences between OCTAVE and other evaluations.

No comments:

Post a Comment

Designed By Blogger Templates