Chapter 4 Operationalizing Risk Mitigation

Recommending a risks to avoid would be that:

-It might cost more to mitigate or control a risk than the business stands to gain by operating with the risk in place. -Replacing a vulnerable set of processes with ones that are less vulnerable can be more effective and less costly than attempting to redesign or repair the vulnerable steps or elements.

What does it mean to accept a risk?

Accepting a risk means that management knows and understands the probability of occurrence, the possible impacts, and the possible costs of mitigation but chooses nonetheless to not make any changes to business processes or systems. This approach is, in effect, self-insuring against the risk. Acceptance requires knowing, informed consent; ignoring a risk is simply choosing not to investigate, assess, characterize, or even think about the risk.

How do physical, logical, and administrative controls interact with one another through:

Administrative controls should direct and inform people; logical controls implement those directions in the IT architecture; physical controls reinforce by preventing or deterring disruptions to the hardware, systems, and support infrastructures themselves.

Information architectures and IT architectures are

business that should drive administrative security policies based on the information architecture; the IT architecture then needs to have its administrative, logical, and physical controls driven to support the information architecture's security needs.

Dashboards are used as part of systems monitoring or incident response by

combining highly summarized key performance parameters with ongoing and recent event data, systems managers can see at a glance whether systems are behaving within expected limits, detect whether subsystems have failed (or are under attack), and drill down to get further data to inform incident response decision making.

Activities are not part of information risk mitigation is:

developing an information classification policy and process. Improving product quality is a laudable goal but in and of itself it is not related to information systems security. Information risk management should precede information risk mitigation.

You want to keep a gap from becoming a blind spot in your information security defenses by:

ensuring that systems elements around the gap provide sufficient detection and reporting capabilities so that an event of interest occurring in the gap cannot spread without being detected.

An important role systems monitoring performs in support of incident management is

essential; by bringing together alert and alarm indicators from systems and their associated security controls and countermeasures, monitoring is the watchdog capability that activates incident response capabilities and plans.

Shadow IT systems or elements a concern to information security specialists because:

-Most are written by well-intended users and may be widely used by people in the organization, but quite often they are not subjected to even the most basic software quality assurance measures and are outside of configuration management and control. Hence, they pose potential risks to the IT architecture. -The more complex and dynamic these shadow systems become, the less confidence management should have in the reliability, integrity, and confidentiality of the results they produce. It cannot be shown that shadow IT systems taken as a whole correctly perform business logic or that they attain the CIA levels commensurate with the impacts if they fail.

Legitimate ways to transfer a risk would be:

-Recognize that government agencies have the responsibility to contain, control, or prevent this risk, which your taxes pay them to do. -Pay insurance premiums for a policy that provides for payment of claims and liabilities in the event the risk does occur. -Shift the affected business processes to a service provider, along with contractually making sure they are responsible for controlling that risk or have countermeasures in place to address it.

CVE data and your own vulnerability assessments indicate that many of your end-user systems do not include recent security patches released by the software vendors. You decide to bring these systems up to date by applying patches such as:

-Remediating or mitigating a risk. -Fixing or applying patches to eliminate a vulnerability is the definition of remediating, mitigating, fixing, or repairing a vulnerability.

An architecture assessment includes the following activities of:

-Review of problem reports, change requests, and change management information. -Review of network and communications connectivity, diagrams, wiring closets, etc. These options focus on trying to discern the "as-built" current state of the systems; whether this goes down to the cable-by-cable verification of what's plugged in where could depend on how thorough the baseline needs to be.

SSCP assess the human elements in a system as part of vulnerability assessments as

-every step in every process, whether performed by people or machines, is a potential vulnerability and should be assessed in accordance with the BIA's established priorities. -the vulnerability assessment indicates that no amount of user training or administrative controls can reduce the risk of an incorrect human action to accessible levels, then further physical or logical controls, or a process redesign, may be needed. The BIA should establish the priorities (which processes to assess first and which ones can wait until later).

Penetration testing is suitable for use during systems security verification or is best suited to ongoing monitoring and assessment through:

-penetration testing is most revealing when performed against a baseline already in use for some time, because the risks of people becoming complacent and mitigation controls becoming out of date increase with time. -penetration testing is not useful during verification testing or systems assessment, because by its nature penetration testing is a somewhat cover attempt to simulate a hostile attack, whereas verification testing is a formalized, planned, and monitored activity. c-penetration testing is normally used during post deployment systems assessment and starts with current knowledge of how threat actors attempt to reconnoiter, surveil, select, and penetrate a target; verification starts with a functional security requirements baseline and confirms (via audit, test, or inspection) that each requirement in that baseline still functions properly. Both techniques complement each other during ongoing operational assessment.

We perform ongoing monitoring of our IT systems to ensure that all risk mitigation controls and countermeasures are still protecting us by:

-periodically, gather up all of the event logs and monitoring log files, collate them, and see if potential events of interest are apparent. -routinely poll or ask users if abnormal systems behaviors have been noted. -review systems performance parameters, such as throughputs, systems loading levels, resource utilization, etc., to see if they meet with expectations.

Testing and verification play a role in information security by:

-providing continued confidence in the security of the information systems under test and verification. -highlighting the need for further risk mitigation, controls, and countermeasures. -confirming that countermeasures and controls are still achieving the required degree of protection.

The role of incident response and management in risk mitigation and risk management are that:

Incident response and management are vital to risk mitigation; they provide the timely detection, notification, and intervention capabilities that contain the impact of a risk event and manage efforts to recover from it and restore operations to normal.

How should IT services such as PaaS, IaaS, and SaaS be evaluated as part of a security assessment?

The BIA and the architectural baselines should make clear what risks are transferred to the cloud services provider either in whole or in part, or where their services are assumed to be parts of the mitigation strategy. The security assessment should clearly identify this to as great a detail as it can, particularly for the risks identified in the BIA as of greatest concern.

The role of threat modeling in performing a vulnerability assessment is that:

Threat modeling focuses attention on boundaries between systems elements and the outside world, and this may help you discover poorly secured VPN or maintenance features or tunnels installed by malware.

The usefulness of CVE data as part of your risk mitigation planning is

a great source of information for known systems elements and known vulnerabilities associated with them, but it does nothing for vulnerabilities that haven't been reported yet or for company-developed IT elements.