As part of my continuous research, CPE, and just a basic need to understand what I’m reading during my job . . . .
I have recently been reading and hearing a lot about how auditors and examiners are asking institutions to integrate threat modeling into various risk management processes such as Awareness Training, Change Management, and Software Development Lifecycles. Taking the last as an example, by implementing threat modeling into the design phases of an application, the application development process grows risk mitigation strategies organically. By understanding changing threat/vulnerability/risk models, controls can become part of the design rather than a band-aid response to a checklist audit. By knowing everything that can go wrong, we can stay on top of risk mitigation in real time.
There are two different approaches to threat modeling, and I believe that both approaches must be taken when you develop an application in-house. First, we must force ourselves to keep an inventory of the security issues that designers are concerned with in the development of an application. These issues include everything from threats to vulnerabilities, prioritized by likelihood, impact, and value. Value can be ignored to simplify the prioritization process, or it can be a consensus on issues related to ease of remediation, time, cost, and opportunity. With this approach, at any point in time, the development team can show their position and approach to application security.
In the second approach to threat modeling, we are talking about a continual inventory of possible attacks to the application. Having this inventory, you can assess the probability and the potential harm for each of the possible attacks, and thus prioritize mitigation efforts. This second approach attempts to provide the ever-changing answer to the question: what could go wrong with the application?
Both models become a separate framework that we can test our applications against prior to placing them into production. It’s important to distinguish between each approach in order to ensure proper processing, and I’ve found a good way to make this distinction is to know that whereas the second approach delivers a list of current issues, the first approach delivers a strategy document that inventories threat profiles and control strategies. The second approach is a good answer to a good audit question. The first approach is a list of current security priorities.
But the goal of threat modeling is definitely a worth goal: it is intended to integrate security into our way of thinking so we can solve security problems before they arise. The problem is that our current approach is this:
It should really change to be more like this:
I know I simplify but the point is, if we are thinking security throughout the process, we will deliver more secure applications.
All of the above is fine and definitely necessary if you are designing in-house applications. But don’t think you escape this because you’ve found a way to outsource all application development. First, I doubt if you really have outsourced everything. When you really start to take an inventory of all applications on your system, you soon find out there are some little scripts here and a few “amateur databases” there. And don’t forget the open source applications you forgot about!
But more importantly, the applications development you outsource still exposes your system to risk. Anybody who has owned a Windows machine knows this. So do we apply threat modeling to all commercial applications as well?
No. Practice Vulnerability Management.
In a way, Vulnerability Management is a superset to threat modeling. In threat modeling we’re brainstorming lists of possible attack vectors and developing models of how to combat threats via detective, preventive, and reactive controls. We prioritize mitigation strategies and integrate them as much as possible into the design of a system.
In Vulnerability Management, we hope our application developers are being transparent and honest in their own threat modeling, and map vulnerabilities to applications (regardless to who is developing them). We are ultimately liable for risk management not only of our own in-house developed applications, but also those applications produced by publishers ranging in size and sophistication (and threat models) from Microsoft to Cisco to the Web-Design-Firm-Down-the-Street. Vulnerability management should be practiced through taking an inventory of all applications mapping four concerns: the applications, their inherent vulnerabilities, mitigating controls and control strategies, sources of vulnerability news.
When we say inventory your applications, we’re talking home-grown and commercial applications. And when we say commercial applications, we’re including consumer, off the shelf software packages, along with industry packages along with all the shareware and open-source utilities your team has picked up over the course of the system’s life.
Vulnerability Management is the goal to map out dependencies on known software packages. Coupling an inventory of software packages with a vulnerability monitoring discipline of security mailing lists as well as vulnerability scanning methods, vulnerabilities can be identified as they emerge into your environment.
The more I think of it, the more I wonder if Vulnerability Management isn’t going to be the glue that ties together all of the sub-processes of IT Governance. For now, I can see it connecting Awareness Training, Change Management, and SDLC processes.
I’m not yet sure what solutions there are out there besides a good spreadsheet (and you all know how I can throw that together.) But I will be researching this more over the next few months. Let me know if you’re interested, and I’ll keep you up to date.
Dan’s New Leaf is a blog by:
Dan Hadaway, CISA, CISM, CRISC