May 13, 2020 • Published by Jeff Wilder
Risk Management
Individuals in the security industry often comment that the foundation of any company’s security program is its policy and procedures. I am not saying they are incorrect; however, I do not believe they see the big picture. Policy and procedures look to address risk, but they do not define it. Therefore, the foundation of any security program is formed by the activities around risk identification.
Every security program that I tend to deal with requires that there be some form of risk assessment. Generally, it’s left as that; just a simple line or two. However, in my humble opinion most organizations do not truly understand the context of what it is asking for and assessors often let their clients slide on the issue. Perhaps, it is because they themselves do not understand.
In this blog, I want to share with you the lifecycle of a formal security risk assessment program.
There are numerous frameworks out there for “Risk Assessment,” but each can be broken down to the following attributes:
If your program does not address all these topics, you are likely missing an important part of the puzzle.
Security risk needs to be examined from any perspective that can impact the organization to deliver its services or products to its client. When I am referring to clients, these are internal as well as external; they are the people you serve. If you are a server administrator, your clients are not only the customers that connect to your website to purchase things, but also the internal staff who connect to your email server to conduct business.
When starting your risk identification process, you need to consider people, process, and technology. For example, if you are operating a health care organization and your nursing staff goes on strike, people are your risk. If legislation is enacted that requires you to bill differently to get refunded from the government, your processes are at risk. And technology…I hope you understand how that may be a risk to your organization.
It’s equally important to fully identify all systems that are employed, from each business unit, that are used to serve your clients. Once again, this should be internal and external customers. If your Web server goes down, you may not be able to sell widgets. If your payroll servers go down, people may not return to work until they get paid. Work with each portion of your business using your data flow diagrams and inventory lists to ensure that you have accounted for each asset.
Asset valuation is not just about the cost to repurchase the device. This attribute should include the cost and time required to put it back into a production state and most importantly, the value to the company. For example, a single POS device may cost a few 100 dollars to replace, but it generates a few thousand dollars an hour in cash flow. In other words, having a POS down for 10 hours a day may cost $10,000 in lost revenue However, if that asset is compromised and sending cardholder data out to an attacker, it may be as much as an aggregate cost of a 30-40K a day.
Just have a look at the total costs of actual and lost opportunity of the Target breach. Had you said that a POS system that has malware on it would cost an organization of somewhere around half a billion dollars, would you be believed? When looking at asset valuation, it is important to fully understand the true value of an asset, not just the cost. They are two different things.
If you say that the Southern coast of Texas may get hit by a major weather event, I will say that the probability of that is fairly certain. However, what about a hurricane hitting New Jersey? Wikipedia notes that there have been 10 events registered as a hurricane since 1940. So, depending on the asset, the risk, and its location, the likelihood of the impact will change. As I live in Colorado, I can’t find a record of one happening here. When looking at the likelihood of impact, do your research to find real numbers. This shouldn’t be a “well I think it will happen .02% of the time.” If you cannot find specific evidence, you should plan for a worst-case scenario.
Now that you have a list of your assets, a list of the risks that can be imposed upon them, asset valuation and the likelihood of impact, you are ready to run the numbers or ranking process.
Risk valuation= ((asset valuation x likelihood of impact) x Asset Valuation)-existing controls. This is done for each risk, for each asset. The value that this comes up with is somewhat of an arbitrary number or value. Values used (quantitative or qualitative) will provide you with a list of risks and the risk value of a risk against a given asset. While stated, they are arbitrary. What you will see is that it starts to identify those areas that present the highest security risk to the organization, both internal and externally facing.
So, now what? You have a number or value; high, low,10,94… whatever the value is, it is arbitrary. What do we do with it and where do we go from here? Executive staff needs to identify their appetite for risk.
A few weeks ago, I published a post that highlights the importance of monitoring events and reporting those events back to the business owners to ensure the efficacy of their programs. This concept is no different. Remember, the IT staff does not own risk within an organization; that belongs to the business owners and ultimately the Board of Directors. In this situation, the results of the assessment of security risk needs to be provided to the owners of that risk to determine if the risk valuation is at a level which is acceptable to them.
As Colin Powell would say, “Once you break it, you are going to own it.” This is no different here. It’s leadership’s responsibility to define the level of acceptable risk. Some processes may have more risk than others, as will some assets. But leadership’s role in this is now to examine the risk to:
In accepting the risk, they can decide that the level of risk posed by a specific threat against a given asset is not high enough to expend resources to fix it. If the risk is too high, specific actions must take place in order to reduce the level of risk to an acceptable level. The worst case is that they deny or ignore the risk. This places the organization at the greatest risk. And lastly, is to defer it. This is where the organization looks to defer risk by purchasing an insurance policy to cover the costs in the event.
The net result of these actions is a risk treatment program that has identified risks, including those that are too great for the organization to just merely accept. Those are the risks that need to be addressed.
With this knowledge in hand, we can now examine our policy and procedures, as a method to address and reduce risk of a threat against a given asset. It’s not the chicken and the egg conundrum; your security risk assessment must be comprehensive and come first.
Want to learn more about security risk management? Click here to see all our blog posts on the topic and subscribe to this blog for future posts.