Comment (0)

Lately we have seen a lot of focus on security in social media – professionals, companies, organizations trying to increase security awareness. A lot of the information out there is about “control” and “compliance”. The downside of a risk management regime based on strict rules, controls and compliance measures has been demonstrated again and again throughout history, and I’ve also written about it before in terms of getting users on board with the security program. My background is from the oil and gas industry – an industry that has seen several horrific accidents. Two of the more well-known and dramatic ones are the Piper Alpha accident 30 years ago this year, and the Deepwater Horizon blowout in 2010. In both of these cases, investigations pointing to “root causes” concluded with a degraded safety culture, lack of attention to real risks and partially blamed a prescriptive approach to safety. The same arguments are equally valid for security incidents. The goal should be to find a balance between security and operational flow.

Some Examples of Potentially Unhelpful Helpfulness

If you are looking for security advice online, it is easy to find. A lot of it will tell you to “trust nobody, lock down everything”. From a traditional security point of view, this makes sense – but it does not take the risk context into the picture, nor does it balance measures against operational needs (such as keeping your store open, or being able to try new things to innovate and create new products).

Here’s Dr. Eric Cole (he knows a lot about security but sometimes I think his advice is a bit draconian)

Change control is important – but gathering a “change control board” for every change you do may be overkill – if you want to stay “agile” and able to respond to changing demands.

Another common “rule” that actually does make a lot of sense is not to give end-users admin rights to their work computers. But… needs will vary. If you are trying to develop new technology but your developers have to go through a lot of red tape to try out a new technology, it will certainly have some ill effects on your team’s ability to innovate. On the other hand, giving developers all free reigns in the name of the “sacred innovation gods” is also not a very good idea. The whole thing is about balance.

Risk Acceptance and Balance

Security controls are often cumbersome for people. Airport security, nightclub bouncers, two-factor authentication, no admin rights. Security leads to a limitation of access in a large number of cases. This obviously has a downside when it comes to how fast we can innovate, how quickly we can produce. The benefit is reduced probability and impact of a major incident – and such incidents are very expensive. The amount of security cumbersomeness people are willing to accept and live with will normally depend on how bad it can get if someone hacks you. If your system controls nuclear weapons, a power plant, or perhaps the production at a chemical plant, incidents can cause real disasters leading to financial and environmental ruin, as well as a large number of fatalities. In this case, you will probably accept a lot of security controls to minimize the chance of something like that happening.

On the other hand, if you are selling some new hot service online, you still need people to trust your service, and you need to comply with privacy laws. This means your security must still be good – but you may nevertheless adopt a slightly higher risk acceptance than in the nuclear weapons case.

The trick is to find a good balance between acceptable risk performance, and good operational flow. This in itself will contribute to greater security performance overall, as the human factor side to cyber risk is very large, something that is often undervalued when designing security controls. To do this in a coherent manner we bring you the mighty tool of the…. risk-based threat model.

Threat Models for a Balanced Security Strategy

A threat model is best made for a specific system or subsystem. The system can be everything from “the company network” to a specific application or a small software component. The thinking remains the same but the details in your model will change. The whole purpose of it is to understand how and Adversary can perform an Action on a Target to achieve an Objective. There are many ways to model this explained in the literature, but we won’t go into details about them here. If you want the details you can search for attack trees, STRIDE, cyber kill chain.

Context. You need to understand 3 things about the risk context:

• Who are the stakeholders and what is their interest in the system? Owners, employees, users, customers, suppliers, attackers, insiders
• What does the system itself do?
• Who are the threat actors? Use threat intelligence to understand how adversaries approach the system and the supply chain you are a part of.

Inventory and data flow. Create a data flow diagram on the architectural level. Include relevant information such as protocols and main technologies. Describe what each asset is used for, and make a list of what data is being processed and transferred. Make trust boundaries visible in your diagram. For the inventory, consider the potential impact of confidentiality, integrity or availability losses.

Abuse cases. Consider how the various processes and data transfer operations can be abused by an adversary with sufficient access. Access can be physical access, stolen credentials, through malware or direct use of software vulnerabilities. The abuse case is your primary tool for understanding how controls can stop the adversary’s actions.

Detection and mitigation. Your system is probably not wide open to attack. List the most important controls you have in place already. The main purpose of this is to check if you are missing something obvious that you probably should be doing to stop attacks.

Evaluate and prioritize. Evaluate the threats according to the estimated risk. Prioritize controls that will help you reduce the risk of unacceptable actions being taken by adversaries to your most important assets and operational capabilities. Make sure you do not over-stretch the organization’s capabilities – focus on what matters the most first.

Thinking through your context and what you value brings you a long way alone, in particular with solid baseline controls. Maintaining a threat model that is kept up to date regularly with new threat intelligence and other context changes also allows you to ensure you do not fall behind how the world moves. Taking risks is fine, but know what risks you can afford to take – when you do that, you can choose the point for balancing security and performance.

Comment (0)