Managing your organization’s Information Security is all about managing your organization’s risk. It is very difficult for the average business owner to understand their information security priorities. Many organizations fall into the trap of looking at only what’s in the news lately, or pursuing the newest “bright and shiny” tools on the market. Other common faults are ignoring the problem entirely and only reacting to issues after they become a problem, or spending money and time only on the most visible parts of information security, such as passwords, or physical devices, or the organization’s internet-facing website. This leads to wasted time and money, ineffective information security protection, and a very stressed out information security team.
By contrast, one of the best ways to manage information security is to start with information risk. By working from a risk-based perspective, your organization can identify risks to be addressed, determine which risks should be prioritized, and understand which risks are being addressed versus being left on the back burner (which is a totally OK thing to do.) This method also has the benefit of being similar to other corporate risk management methods, so often times business leaders are familiar with similar processes already.
There are many frameworks you can look at to see how information security risk is addressed at an enterprise level, including the NIST RMF1, FAIR2, OCTAVE3, ISO:270014, and more.5 In general, they all make risk assessment a main priority of the organization.
The major steps of each of the above risk management frameworks are:
- Identify your sensitive information and systems.
- Identify how that information or system might be compromised.
- Identify how likely a compromise is likely to occur.
- Identify how bad it would be for your organization for each specific compromise to occur.
- Identify what you can do to reduce the risk of a compromise occurring, or reduce the impact of a compromise if it does occur.
- Identify how much time, effort, and money implementing each protection would take.
- Determine which protections are actually worth pursuing.
- Determine the order in which you want to address the protections.
- Actually implement the protections.
- Maintain the implementations over time.
Below, we will explore each step in more detail.
Identifying your sensitive information and systems:
First, I want to introduce a central concept of information security – the CIA Triangle. Information Security, as a field, is concerned with three things – the confidentiality of a piece or type of information, or an information system, the integrity of information, and the availability of information.
Confidentiality is the quality of only being known (or accessible) to people who are approved to access it. Your Social Security Number is confidential, because it can be used for identity fraud. Your company might have client lists, proprietary information or trade secrets, or regulated information – such as a US-based company with Patient Health Information (PHI), which is required to be kept confidential by the Health Information Portability and Accountability Act (HIPAA).
Integrity is the quality of being protected against unauthorized or untracked changes. Information has integrity when we can be sure that it has not been changed since it was recorded, or that any changes to it were authorized. Systems have integrity when we can be sure that they are configured and operating the way they were configured to during setup, and that any subsequent configuration changes were approved. Organizations often have integrity requirements for customer information, internal policy and procedure documents, communications between the organization, its staff, and its customers, and so on.
Availability is the quality of being accessible when information (or a system) is needed. Organizations often have availability requirements for their email system, website, payment processing systems, and other core business systems.
By looking at these three qualities and thinking about your organization’s systems and information, you can probably come up with a long list of things you care about – and this list is probably going to grow over time, as you think about it more, as issues come up, and as your organization grows and develops.
There is no hard science to developing a list of risks – it can be useful to search around online for what similar organizations have identified as risks, as well as looking at common risks identified by information security organizations and insurance providers. What is most helpful is often simply just brainstorming a list of risks onto a piece of paper. It can be helpful to meet with other parties within your organization, and to ask in trade associations and other networking groups. The most important thing is to start thinking about these things early, and to keep track of risks as you identify them.
Identifying how information and systems might be compromised:
This is called “Threat Modeling”, in Information Security speak. Your basic goal is to look at the things you identified as important above, and figure out ways that it can lose confidentiality, integrity, or availability. For example, you might decide that a big risk for your company is an employee emailing out sensitive information to someone they shouldn’t. Or maybe you run an e-commerce site, and know that if your website goes down, you will lose a lot of money due to loss of potential sales.
It can be difficult to imagine all the ways that things can go wrong, especially without a background in information security, but there are a few things you can do to help yourself brainstorm.
The first thing that you should do is look at some of the ways that organizations are commonly compromised. There are countless news articles about organizations suffering cybersecurity incidents, and there are countless websites providing analysis of these risks. Some lists worth reviewing are NIST’s Cybersecurity Risks list or CrowdStrike’s Common Cyber Attack list.
Secondly, always remember to think about both deliberate attacks and accidental errors. While a clerk at your organization may not mean to send sensitive information outside of the organization, sometimes mistakes do happen, and they are risks all the same. Also keep in mind the CIA Triangle, as discussed above. It is a very useful model for thinking about risks themselves, as well as the threats that may make them become a reality.
Identify how likely a compromise is to occur:
Now, we have our list of risks and the threats that might happen to them. It can be tempting to start planning how to resolve them right away, but first we need another couple pieces of information. The first one is likelihood, and that is what we will look at in this section. Likelihood is the answer to the question “how likely is it that a threat actually occurs?” We don’t want to spend a lot of effort and money addressing a threat that probably is never going to happen, even if the consequences of that threat might be severe.
There are two ways to make this assessment. We can either assess these threats qualitatively, or quantitatively. Qualitative assessments assign threat likelihood according to general categories, such as “Low”, “Medium”, “High”, “Very High”, etc. On the other hand, quantitative assessment assigns likelihood based on measurements, history of past compromises, etc. While it may seem like Quantitative assessments are “better”, it is really a question of effort versus reward. Quantitative results take much more time and energy to figure out compared to qualitative assessments. It is okay for our purposes to simply use qualitative measures to determine likelihood, rather than getting too exact.
Determining likelihood using a qualitative model mostly involves looking at each threat and asking yourself how exposed you are to each threat. A device that is disconnected from the internet and locked in a closet has a very low exposure. A device that can be accessed from the internet by anonymous users, or which can be physically accessed without any supervision or escort has very high exposure. Other risks, like employees accidentally sending one client the proprietary information of another, will have higher exposure if they occur frequently, if there is a lot of employee turn over, if employees performing that task are not trained appropriately or often have to rush, etc. You can also look at past incidents for a clue as to what incidents may occur again.
Identify how much of a negative impact each compromise would have:
Luckily, the next step is easier to make sense of, even for people who don’t work in Information Security. Once you have your list of threats and their likelihood, it is time to assign them severity levels. A device that is “mission critical” and necessary for your day to day work – an e-commerce website, for example – likely has a very high impact rating for any threats that might take it offline. Information leaks are often high impact due to the fact that you can’t “put the genie back into the bottle” after information is leaked. Once it’s out there, it’s out there.
When determining impact, you should consider things like how valuable the information the device hosts is, how critical to your business processes a system is, and so on. You should also things about things like the safety and privacy of your clients and employees, the impact to your organization’s public reputation, and any regulatory requirements you have. Be realistic – it’s okay to say that an impact would be relatively small or would be company-ending.
Remember to keep in mind also that a compromised, low-importance device can often be used to provide access to a much higher sensitivity device that is otherwise not vulnerable. As an example, often times important databases, stored deep within the company’s network, are breached because a little-used, internet-facing web server is compromised and used as a “pivot point” by an attacker.
Identify potential ways to reduce the exposure (or impact of compromise) of the threats identified:
Next, we have to look at what our options are to treat these risks. Risk treatments come in a very wide variety of options, but we can group them into three major types.
Mitigate – When you choose to mitigate a risk, you are choosing to change something about how your organization operates to reduce the likelihood or impact of the threat. Examples include big things like implementing a patching and vulnerability management program, or small things like color-coding printer paper so that it’s easier for clerks to tell one client’s information from another’s.
Transfer – When you choose to transfer a risk, you make it someone else’s problem… sort of. The most common example of transferring risk is buying insurance. You look at risk and decide you either can’t mitigate it, or it would cost too much to do so, but accept that you can’t just leave it alone, so you buy insurance. This comes with its own cost, and for a lot of kinds of cybersecurity insurance, will come with its own requirements to run a cybersecurity program – insurance companies don’t want to insure someone who does nothing to reduce their risk.
Accept – Accepting a risk is simply deciding that the risk isn’t worth the effort to address. While it may seem “wrong”, in risk management it is perfectly acceptable to simply let a risk be. Sometimes it costs more to address a risk than the risk is likely to cost, so it makes the most business sense to simply leave it be.
So, for each of these threats we’ve identified, first we think about what mitigations are available. Then, we decide whether any of those mitigations are appropriate, or if it would be better to transfer or accept the risk.
Let’s look at a quick example – Again consider the clerk who handles mailing sensitive customer information, with the risk of mixing up what is mailed to whom, and accidentally mailing one customer’s sensitive information to another. You might decide that it’s a high likelihood risk, and it would have a serious negative impact on your relationship with your customer. You determine that you have a few option for mitigation – you might train the clerk on the important of checking twice, or provide them with a way to physically organize their desk to prevent mix-ups, or decide that another employee has to check the contents of each envelope before they are sealed. You decide that you want to do all of these together, and write them into the mitigation plan.
Or, as another example, let’s consider a company with an unimportant, publicly accessible website, and a sensitive database inside their network. The company might decide that the public website has a very high risk of being attacked, and that if it were compromised, it could give access to the sensitive database to an attacker. The company might decide that the server should be kept on a separate part of the network from the web site, so that it is much harder for an attacker to pivot from one to the other. The web server might still be vulnerable to attack, but because it is so low importance, it is okay to leave unprotected, as long as it being compromised doesn’t endanger the rest of the network. This is an example of mitigating a risk and accepting the remainder (a.k.a. “residual”) risk.
Finally, as a third example, a company might determine that they have a large risk of being hit with ransomware, but the cost of any protections against it is too high to afford. That company might decide that it makes better financial sense to take out an insurance policy against cyberattacks, or to simply “self-insure” against the cost of a ransomware attack by setting aside enough money to pay the costs of fixing a ransomware attack.
Determine the priority for risk treatments:
Determining priority is really where all of this effort pays off. While the above sections are very useful to understand and visualize your current concerns, prioritization is where you can really turn all of the above into a security program.
Fortunately, prioritization is also very simple. Simply look at each risk, its impact, its likelihood, and what the effort involved to address it is, and rank the different initiatives accordingly. Be sure to avoid the trap of only addressing “low hanging fruit”. It is tempting to hit all the cheap, quick, and easy objectives without ever addressing the larger problems. While it is good to address the small things, information security is ultimately a holistic engagement – one insecure system can take down an entire network, and one highly secure system on an otherwise insecure network will be much easier to compromise. It is important to make sure that the entire system is resilient enough that no obvious “open window” is left to attack while also ensuring that the “high value” targets are given careful attention.
For example, if you have determined that you need to spend $2000 per year on employee security awareness training, and it will take 20 man-hours per year to set up, orchestrate, and manage, you might decide to do it, and will probably see improvement from it. It would reduce the risk that an employee get phished and give an attack a way into the network. If you also have determined you need to spend an extra $50k/year on software and hire a full-time security engineer to properly configure and secure your network against intrusion, and decide to not do it, you still have a gaping hole, even if one avenue of attack into that insecure network (employees being phished) has been addressed. Only if you do both will you properly address the risk of network intrusion.
This is not to say that every single risk you identify needs to be closed. Sometimes it really is too much effort to close a small hole, or there’s simply too many little things to be done for an organization of your size. This is okay, so long as you are looking at these risks in the context of the security of the entire network, and deciding if they are “shooting yourself in the foot” to leave them unaddressed.
Implement the solutions:
Finally, we are onto implementation. While the actual details will vary widely based on the specific issue, you can generally use the same process to track and facilitate this step.
First, I want to point out that the document you’ve produced so far is essentially a Risk Register. You can use it to track all of your risks at a high level, and keep tracking them until they are addressed. You can even use your historic risk registers to re-examine old risks and make sure they are still addressed down the road, as your organization shifts and changes and grows.
Second, it is important to track the progress of each mitigation implemented. While not every fix will require a project management program to be implemented to support it, it is always useful to determine useful metrics – how will you know when the fix is implemented? How will you know it was effective? A good example is phishing education and awareness. You will know it’s implemented when the mock-phishing system is online and sending out phishing tests successfully. You will know the program is effective when you see the click-rate or incident rate go down compared to before hand.
Maintain the solutions:
An easily overlooked step is the maintenance of each fix. While some fixes are one-and-done, such as applying a patch, many implementations will be ongoing. Examples include policy and administrative controls, surveillance systems, or management programs, such as a vulnerability management program. It is important to make sure that you do not move onto “the next big thing!” once the solution is in place. All of IT rots when it is not maintained, so it is important to periodically check back on each fix every so often and ensure that it is still functioning as intended, and still addressing the risk as needed.
Attachments:
Here is a copy of a Risk Register template that you might use to facilitate this process. Included in it is an example of how a risk register might be completed for a small company with PHI concerns.
- https://csrc.nist.gov/Projects/risk-management/about-rmf ↩︎
- https://www.fairinstitute.org/what-is-fair ↩︎
- https://insights.sei.cmu.edu/library/operationally-critical-threat-asset-and-vulnerability-evaluation-octave-framework-version-10/ ↩︎
- https://www.iso.org/standard/27001 ↩︎
- https://www.csoonline.com/article/525128/it-risk-assessment-frameworks-real-world-experience.html ↩︎