What is risk in information security

Information security risk management, or ISRM, is the process of managing risks associated with the use of information technology. It involves identifying, assessing, and treating risks to the confidentiality, integrity, and availability of an organization’s assets. The end goal of this process is to treat risks in accordance with an organization’s overall risk tolerance. Businesses shouldn’t expect to eliminate all risks; rather, they should seek to identify and achieve an acceptable risk level for their organization.

Identification

• Identify assets: What data, systems, or other assets would be considered your organization’s “crown jewels”? For example, which assets would have the most significant impact on your organization if their confidentiality, integrity or availability were compromised? It’s not hard to see why the confidentiality of data like social security numbers and intellectual property is important. But what about integrity? For example, if a business falls under Sarbanes-Oxley (SOX) regulatory requirements, a minor integrity problem in financial reporting data could result in an enormous cost. Or, if an organization is an online music streaming service and the availability of music files is compromised, then they could lose subscribers.
• Identify vulnerabilities: What system-level or software vulnerabilities are putting the confidentiality, integrity, and availability of the assets at risk? What weaknesses or deficiencies in organizational processes could result in information being compromised?
• Identify threats: What are some of the potential causes of assets or information becoming compromised? For example, is your organization’s data center located in a region where environmental threats, like tornadoes and floods, are more prevalent? Are industry peers being actively targeted and hacked by a known crime syndicate, hacktivist group, or government-sponsored entity? Threat modeling is an important activity that helps add context by tying risks to known threats and the different ways those threats can cause risks to become realized via exploiting vulnerabilities.
• Identify controls: What do you already have in place to protect identified assets? A control directly addresses an identified vulnerability or threat by either completely fixing it (remediation) or lessening the likelihood and/or impact of a risk being realized (mitigation). For example, if you’ve identified a risk of terminated users continuing to have access to a specific application, then a control could be a process that automatically removes users from that application upon their termination. A compensating control is a “safety net” control that indirectly addresses a risk. Continuing with the same example above, a compensating control may be a quarterly access review process. During this review, the application user list is cross-referenced with the company’s user directory and termination lists to find users with unwarranted access and then reactively remove that unauthorized access when it’s found.

Assessment
This is the process of combining the information you’ve gathered about assets, vulnerabilities, and controls to define a risk. There are many frameworks and approaches for this, but you’ll probably use some variation of this equation:

Risk = (threat x vulnerability (exploit likelihood x exploit impact) x asset value ) - security controls

Note: this is a very simplified formula analogy. Calculating probabilistic risks is not nearly this straightforward, much to everyone’s dismay.

Treatment
Once a risk has been assessed and analyzed, an organization will need to select treatment options:

• Remediation: Implementing a control that fully or nearly fully fixes the underlying risk.
  Example: You have identified a vulnerability on a server where critical assets are stored, and you apply a patch for that vulnerability.
• Mitigation: Lessening the likelihood and/or impact of the risk, but not fixing it entirely.
  Example: You have identified a vulnerability on a server where critical assets are stored, but instead of patching the vulnerability, you implement a firewall rule that only allows specific systems to communicate with the vulnerable service on the server.
• Transference: Transferring the risk to another entity so your organization can recover from incurred costs of the risk being realized.
  Example: You purchase insurance that will cover any losses that would be incurred if vulnerable systems are exploited. (Note: this should be used to supplement risk remediation and mitigation but not replace them altogether.)
• Risk acceptance: Not fixing the risk. This is appropriate in cases where the risk is clearly low and the time and effort it takes to fix the risk costs more than the costs that would be incurred if the risk were to be realized.
  Example: You have identified a vulnerability on a server but concluded that there is nothing sensitive on that server; it cannot be used as an entry point to access other critical assets, and a successful exploit of the vulnerability is very complex. As a result, you decide you do not need to spend time and resources to fix the vulnerability.
• Risk avoidance: Removing all exposure to an identified risk 
  Example: You have identified servers with operating systems (OS) that are about to reach end-of-life and will no longer receive security patches from the OS creator. These servers process and store both sensitive and non-sensitive data. To avoid the risk of sensitive data being compromised, you quickly migrate that sensitive data to newer, patchable servers. The servers continue to run and process non-sensitive data while a plan is developed to decommission them and migrate non-sensitive data to other servers.

Communication
Regardless of how a risk is treated, the decision needs to be communicated within the organization. Stakeholders need to understand the costs of treating or not treating a risk and the rationale behind that decision. Responsibility and accountability needs to be clearly defined and associated with individuals and teams in the organization to ensure the right people are engaged at the right times in the process.

Rinse and Repeat
This is an ongoing process. If you chose a treatment plan that requires implementing a control, that control needs to be continuously monitored. You’re likely inserting this control into a system that is changing over time. Ports being opened, code being changed, and any number of other factors could cause your control to break down in the months or years following its initial implementation.

Ownership:

There are many stakeholders in the ISRM process, and each of them have different responsibilities. Defining the various roles in this process, and the responsibilities tied to each role, is a critical step to ensuring this process goes smoothly.

Process Owners: At a high level, an organization might have a finance team or audit team that owns their Enterprise Risk Management (ERM) program, while an Information Security or Information Assurance team will own ISRM program, which feeds into ERM. Members of this ISRM team need to be in the field, continually driving the process forward.

Risk Owners: Individual risks should be owned by the members of an organization who end up using their budget to pay for fixing the problem. In other words, risk owners are accountable for ensuring risks are treated accordingly. If you approve the budget, you own the risk.

In addition to risk owners, there will also be other types of stakeholders who are either impacted by, or involved in implementing, the selected treatment plan, such as system administrators/engineers, system users, etc.

Here’s an example: Your information security team (process owner) is driving the ISRM process forward. A risk to the availability of your company’s customer relationship management (CRM) system is identified, and together with your head of IT (the CRM system owner) and the individual in IT who manages this system on a day-to-day basis (CRM system admin), your process owners gather the information necessary to assess the risk.

Assuming your CRM software is in place to enable the sales department at your company, and the data in your CRM software becoming unavailable would ultimately impact sales, then your sales department head (i.e. chief sales officer) is likely going to be the risk owner. The risk owner is responsible for deciding on implementing the different treatment plans offered by the information security team, system administrators, system owners, etc. and accepting any remaining risk; however, your system owner and system admin will likely be involved once again when it comes time to implement the treatment plan. System users—the salespeople who use the CRM software on a daily basis—are also stakeholders in this process, as they may be impacted by any given treatment plan.

Managing risk is an ongoing task, and its success will come down to how well risks are assessed, plans are communicated, and roles are upheld. Identifying the critical people, processes, and technology to help address the steps above will create a solid foundation for a risk management strategy and program in your organization, which can be developed further over time.

Compliance and Regulatory Frameworks