In a
previous post, I noted some security issues that I had observed during recent visits to medical professional offices and hospitals.
In reflecting on that post, I realized an important aspect of the disconnect I experienced as I observe security around me.
It is that I carry with me a threat model that is probably very different than the threat model applied by others. My primary
threat model is focused on accessing computer systems. It is in my nature as a software developer who is focused on security to see this as the most useful threat model and it has served me well.
However, when I think about systems outside of my specialty – like doctors' offices and hospitals – I need to recognize that I am applying a threat model that has different basic assumptions about what is valuable than that used by the system's owners.
One of the first steps in threat modeling is defining your security policy, i.e., what is valuable and in need of protection. When working on software development of a single product, focusing on system access is easy to agree on and move on without too much thought or argument. But when you step out of that environment and apply those assumptions to other situations, you can make some mistakes about what is important in that system.
To my peers and I, the threat model we focus on is about network access and protecting data – this is a very software product focused process. When I encounter a system like that in a doctor's office, I can see that there are gaps in the threat model from my perspective, where network access and infiltration are my "goals."
What I miss is that the security policy in that location is focused on physical security (don't get all of your computers stolen) and ease of use.
Since we don't share similar priorities, I see gaps in security that could be exploited but in the light of running a medical office, "sophisticated" attacks like a patient inserting a USB drive or navigating the desktop and finding your wireless access point credentials are not your primary concerns and the cost of mitigating them may seem too high.
I personally run into this all of the time, applying my set of values to other systems can help find faults in that system but can also make you assume that something is a problem when in fact it isn't in the light of the appropriate security policy.
One might argue that this is less relevant today and that being able to access a network at all is "ALL CAPS BAD" because of our increasing interconnectedness, and I would have to agree.
It will take time for administrators of small office systems like these to incorporate changes to their threat models – that or they will outsource it to a common infrastructure. In fact, several of my doctors belong to a group that clearly provides software and data exchange as part of their network but it isn't clear what level of IT support they provide.
Outsourcing IT functions will be good for the security of doctor's offices but will introduce other issues around privacy and data protection. Ultimately, it will migrate the responsibility of the doctor's office to run an IT department into a professional, and hopefully mature, IT organization. One that no individual doctor's office could support and that can focus on holistic threat models for these sorts of organizations.
In light of this, I will pay closer attention to the assumptions I make about what is important in a given security environment because it isn't about absolute security, it has to do with the deployment environment, as well.
As always, check your assumptions before making an issue out of something. And remember, there is an option in threat modeling to accept a given risk because what is important is more than just the ability to do something; the likelihood of it happening has to be taken into account.
Title image courtesy of ShutterStock
