Coming from Perth, of course I’ve worked in mining. Since moving to a role that focuses on security I’ve always been curious about how safety has been able to be a top priority in the resources industry. It’s something that everyone thinks about. Security is often trying to do the same thing. This is a topic I spoke about at CyberWest Summit 2024 and in this post I look at lessons we as security professionals can learn from safety culture. I believe we can leverage similar ideas to make security just as important for everyone as safety.
If you were to previously ask me what security and safety have in common, I would have sarcastically said “I’ve been told in the past that both are someone else’s job.” When working on a financial reporting system I realised anyone could place a message in a queue and have it processed down stream. When I questioned the security I was told “don’t worry about it, that’s security’s job to pick up.” Later, when working on a logistics system, I raised that we should consider the safety of our systems role. For example, we needed to ensure two pieces of equipment were not in the same place at the same time. Again I was told, “don’t worry about it, it’s the drivers job to ensure that an accident doesn’t occur.” In both cases I’d identified an issue that posed a risk to the business early. We could have easily mitigated those risks early in the development process.
Both security and safety have similar objectives. Often the first thing people focus on in information security is the CIA triangle. Confidentiality - keeping information private. Integrity - ensuring that information remains intact so we can trust it. Availability - ensuring that we can continue to access it. Safety can be seen through a similar lens . We want to ensure that people are able to go home to their families. We don’t cause any hard to people or our business. We want to ensure that safety issues don’t cause outages. The way this is primarily done in the resources industry is through culture. You’ve probably heard the Peter Drucker quote “culture eats strategy for breakfast.” The key is that strategy is what we would like to do. Culture on the other hand is what we are actually doing.
This culture of safety starts at the top and applies to everyone at the organization. A story that always sticks with me from my father is from his experience meeting a group of mining executives. As soon as the meeting started the building siren went off. They reassured him that it was just a drill. My dad thought great, they could go on with the meeting. Instead, the very senior, very busy people re-iterated that they took safety seriously. They had to take part even though it was only a drill. I’ve seen a similar approach during my time at Amazon Web Services. The CEO regularly talks about how security is our top priority. At Amazon, the leadership principles act as a guide to how decisions are made and ownership is one of them. Teams own their outcomes as a business does . They own the profit and loss, the availability, customer satisfaction and business risks. Security risks are business risks. Those team own them and design their systems from the start to be secure.
Safety recognises that people need to be at the centre of the approach. It’s ultimately people that we’re trying to protect. Systems are designed knowing that people will operate it. Importantly, people also make mistakes. Systems are designed to work with humans. Consider the safety that goes into a car. We recognise that it goes on the roads where other people will be. We introduce safety systems to reduce the impact if it strays towards a pedestrian. Cars have safety belts and airbags. If humans didn’t make mistakes, cars wouldn’t crash and we wouldn’t need these safety systems. In the same manner security needs to work with humans.
To manage risks you need to identify them. In safety, a “job hazard assessment” or a “take 5” occurs before every job. When I worked in mining we had to do a hazard assessment before relocating office. There were professional movers but we still had to pack the boxes, move them to the right area and repeat on the other side. We recognised that we were in a situation that required us to consider safety. We identified the hazards, assessed the risks and put appropriate controls in place to mitigate the impact or likelihood. In technology, threats are able to impact confidentiality, integrity or availability by exploiting vulnerabilities. Vulnerabilities are introduced by humans when technology is being built and if we can identify those vulnerabilities through a risk identification process then we can put mitigations in place. In security this process is called threat modeling. A common framework for the process comes from Adam Shostack, who uses a four question frame. What are we working on? What could go wrong? What are we going to do about it? Did we do a good enough job? Just like safety, this is a process we can implement before we do work - during design time - to ensure that we are building secure systems.
Any process that we put in place needs practice. The only way to get good at threat modeling is to do it regularly. For safety, fire drills are regularly run in office buildings so we know what to do in an emergency. By practicing our emergency responses we become familiar with where the things we need are, the steps we need to take and who our floor wardens are. For security it is also important to practice our processes. Patching and updating vulnerabilities often and at speed allows us to refine the process and ensure that we have the right tools in place. By practicing incident response we know we have the right access and tools as well as who the points of escalation are. When we then face a real security event we know what we need to do.
After practice and real scenarios it’s important to get feedback to improve the process. In safety whenever there is a safety incident or a near miss, there is an investigation and the results are shared widely. This allows everyone to learn from it and allows for changes in the procedure or additional safety precautions taken. We can learn from security events to improve processes. These investigations are blameless and focus on the systems that allowed the event to occur. By sharing learnings widely other teams can ensure that they don’t have the same issues. It also ensures that systems are changed to prevent repeat events.
In safety there is a hierarchy of controls that are considered. Elimination of the risk being the most effective and personal protective equipment is the last option. In security we can use a range of controls of varying effectiveness to protect our systems. Consider the elimination of a risk. In safety that means removing the danger entirely so the likelihood of the risk becomes zero. This might mean the activity is avoided entirely. When operating technology we can always look at what steps are needed to remove the risk entirely. Consider production access. Removing human access to production ensures that humans can never cause security events. The most effective control would be eliminating that risk. If we really, really need production access, at least put administrative controls in place. In safety is where engineers need to perform maintenance work they can’t remove that risk but they do have an administrative control in place. Engineers have the ability to put a physical lock in an isolation tag out which prevents equipment from activating while the lock is in place. For security we can put an administrative control on production by ensuring that access is only granted through an approval pipeline to vend temporary credentials.
How our systems are designed affect their use. In safety we recognise that people are in the system. As such, sites are designed such that guard rails direct people in the right direction and the right tools are present to ensure that they’re following the safest way. In security we must look at our technology and use that to guide developers in the right direction. Security professionals who build guardrails and build tools such make building securely the fastest way to production. Security teams who work to make build tools easier win a lot of friends with developers. Security teams that avoid saying no and work to enable developers receive more cooperation on security outcomes.
By now, you might be wondering what the best way to start is. I believe that the number one thing is for organizations is to recognise the impact of security. At the core of it, security risks are not about technology. They represent risks to the business itself. This has been widely recognised in safety aware industries for a while. The ability for a company to protect its employees and ensure they can go home safe impacts their social licence to operate. In the same way, everyone is becoming more aware of security. This requires a top down vision for security. Not only that it is important but it is also an area we can do something about. In order to do something about it we need to be aware of the risks. In safety there are processes and routines in place to identify and address risks. For security threat modeling is key. Adam Shostack’s books are great for an in depth discussion of the practice and my Amazon colleague Darran Boyd also has some great material. I’d suggest starting with his blog post in How to approach Threat modeling. That also links to some tools and workshops to help get started.
Cover photo by Yuan Chen on Unsplash. Photo of Byron speaking at CyberWest by David Broadway used with permission from CyberWest.