Threat Modeling
Threat Modeling
For most of us, the concept of ‘Threat Modeling’ takes on different meanings based upon our experiences, areas of expertise, areas of interest and comprehension of what constitutes and is defined as a ‘threat’ by industry and by ourselves. For man, ‘Threat Modeling’ is the realm of the developer. It is an area of expertise, which specifically addresses security, concerns of interest to them while for others, ‘Threat Modeling’ is used during assessment work. It is during these assessments, most of which are specific to code analysis and review, which we see many use these techniques to formulate and define more robust ‘Threat Models’ vis a vis the definition of potential attacks and exploits. Regardless of the definition you subscribe to, we can assume that ‘Threat Modeling’ accounts for much, but does it account for everything we need it to?
Threat Modeling Attributes
It’s important to note that ‘Threat Modeling’ has undergone much change over the last decade. It has experienced evolution and likely will need to going forward as both the application of the act of ‘Threat Modeling’ as well as the philosophy behind it, continues to evolve and grow. This is really rather non-negotiable when one looks at the current state of technological advancement we are in today and where we dare to take ourselves. As a result, we can assume the following of ‘Threat Modeling’:
- There are traditionally three commonly held views of ‘Threat Models’
- Attacker Centric
- Application / Software Centric
- Asset Centric
- ‘Threat modeling’ can be related to any asset deemed to posses worth and be considered of value to an individual or organization
- Personnel
- Facilities
- Applications
- Systems
- Networks
Identification and declaration of exactly what defines an asset is crucial to the process of ‘Threat Modeling’, failure to perform due diligence here will be noted and likely lamented in post mortem investigations.
- It is the desire of the owner or the party(s) tasked with stewardship of the asset in question to protect and ensure the safety of the asset (and any associated / related assets)
If there is any doubt as to whether or not it is the intent of those tasked with responsibility and stewardship for all defined assets, ‘Threat Modeling’, though still important should not be the first order of business!
- All assets have points of vulnerability
- All points of vulnerability can be exploited if left unaddressed or if addressed in appropriately
- Vulnerabilities can be exploited via internal or external means
We live in an imperfect world and as a result, all things; even the most cleverly engineered – organic or inorganic, have flaws. Assuming otherwise is a failure of logic and will almost always lead to a fall. Accepting that all things have vulnerabilities and are susceptible to exploitation knowing that these vulnerabilities can be remediated and the risk mitigated is of paramount importance to the success or failure of ‘Threat Modeling’ exercises or any associated activities.
- Useful in developing in countermeasures
This is of course quite elementary and obvious yet it is something that needs re-enforcement for several reasons not the least of which is that many despite this obvious benefit or by product depending on your point of view, still will not endeavor to engage in formalized ‘Threat Modeling’.
- Can be focused on defense or offense
This, I believe is self-explanatory as one might, again taking into consideration their working definition of ‘Threat Modeling’ into account either look at is as a defensive activity as we discussed earlier or as a mechanism useful, if not paramount, in offensively compromising an asset.
Where to Begin With Threat Modeling?
At a very base level, one needs to ask oneself some key questions prior to engaging in the activity of ‘Threat Modeling’ in order to avoid any oversights or mistakes. These questions are rather elementary yet their value cannot be emphasized enough. They provide the ‘looking glass’ if you will, which is necessary in order to successful model threats and gain the most value from the activity. Some of common questions which one should endeavor to ask and answer may look like (but by no means need reflect verbatim):
- What are the assets you need to protect?
- Where do they reside?
- Who are your customers? User community?
- Who are your adversaries?
- What are your strengths?
- What are your weaknesses?
- What can be done to minimize the attack surface and mitigate risk?
- How often should you engage in this process?
In going through this exercise, trivial though it may seem, a great deal of valuable information and data points may be collected and assessed for their use and application during ‘Threat Modeling’ activities.
Models At Our Disposal
There are many models currently in use today. Some are more focused or directed towards developers while others focus more on the needs of assessors and auditors. Regardless there is no one single way to go about conducting ‘Threat Modeling’. Below are a few wonderful examples of current ‘Threat Modeling’ methodologies & resources:
A View To A Kill: Executing a Threat Model and Processing The Results
- Picking Your Poison: Deciding on Threat Model
- Executing a Threat Model after exhaustive data gathering & analysis of said data
- Post Mortem: Examining the Remains
- Lessons Learned: Planning for the Future
- It’s a Cycle: Wash, Rinse, Repeat
Conclusion:
The value presented by the activity associated with ‘Threat Modeling’ is difficult to argue against. ‘Threat Modeling’ provides a vast amount of data and can aid both individuals and organizations (in quantitative and qualitative terms), in a multitude of ways not the least of which is providing clarity into the vulnerability of an asset or potential for exploitation of an asset. Failure to undertake these activities is akin to dereliction of duty for developers and assessors alike as those with nefarious intent not fail to exhaust every measure at their disposal to accomplish their mission.
Software is an essential, non-negotiable aspect of everything we experience in our daily lives. It is a technological parallel of water to the biological realm. All things within the worlds that govern the use and application of either software or water rely upon the sanctity and “cleanliness” of these resources in order to progress forward and ensure their existence. Without a sense or guarantee of purity, much stands to be lost; most of which can only be hypothesized about or guessed at until an event of interest solidifies the inclinations of those who are speculating. Consider all that you interface with on a daily basis, regardless of where you are located geographically on planet Earth. Your communications systems, your medical and emergency response systems, your transportation systems, your drinking water and water treatment facilities, your power industry systems (end to end), your financial systems, your military systems etc etc. This is a relatively short list and though that may be the case (and though I am fully aware of the greater scope of systems and technologies affected by software), we can see that precious little in the age in which we live exists outside the realm of engineering which is dependent upon secure software development. Traditionally, software development lifecycles (SDLC) have been individually governed either by those parties responsible for the ‘framework’ of tools and / or coding languages which are used for development or by those parties within a given organization who have assumed responsibility for development are actively moving towards goals being set forth by their units of business which they support. Whatever the case may be, there are certainly ample examples of glaring deficiencies within these processes, deficiencies which (when left unaddressed provided they are found or worse, ignored despite having been found), often have cataclysmic ends.
As professionals working in the business world, plying our tradecraft we need to ask ourselves, our clients, our customers and anyone else who will listen (ideally those who have a ‘Stake’ in the decision making process which impacts the generation and delivery of this code), why we allow an insecure state to exist in something so key to our everything we do. There are many reasons one could point to for the existence of these deficiencies:
- Unrealistic time lines for delivery to market by businesses and stakeholders within
a) Meeting or exceeding expectations of the investment community
b) Exceeding the ability of the competition to get to market and thusly secure a more stable position
c) Realization of a conceptualized solution to a need / want in the absence of irrefutable data
- Lack of expertise to ‘code’ securely
a) Coding with security in mind is as much an art as it is a science however it can be, in repeatable fashion via soundly crafted process & procedure in addition to training and encouragement of skill set development be achieved
b) Resource / personnel challenges
- Lack of people capable of marrying the concepts together
- Lack of discipline / time to ‘code’ securely due to pressures presented in point #1
a) Self-explanatory but can certainly be expanded upon in more gross detail at a later time
- Lack of patience
a) Art meeting science; one cannot rush greatness or soundness of design however one can, through the use and employment of the right people, process and technology achieve the goals and complete the mission
b) Patience is non-negotiable
- Fear
a) People fear what they do not understand
b) People fear what they do understand but are unable to influence and / or change
c) People fear what they cannot contemplate
The net effect for our discipline and tradecraft is that we see (and experience daily), the results of either poor or total absence of, proper SDLC. We cannot afford to become comfortable or complacent in a system which has to date, zero accountability and as such many are looking at the present, towards the future with new, bold ideas in mind hoping to effect change. One such organization is one which I have both the privilege and honor of being affiliated with, The Rugged Software Initiative http://www.ruggedsoftware.org/ and https://groups.google.com/a/owasp.org/group/rugged-software. My friend and colleague, Josh Corman, along with David Rice (author of “Geekonomics” and security professional), and Jeff Williams (CEO, Aspect Security) developed this concept and, with the help / guidance of several industry figures, delivered the Rugged Manifesto and initial presentation which they presented and released at SANS Application Security Summit February 5, 2010. This is not the first time an SDLC methodology has been proffered up for the masses however, it is one of the only times which I can readily recall that a collective body of like minded individuals from disparate elements of industry have developed a framework akin to this which they hope to see adopted by the masses as mechanism for combating the threats presented by the deficiencies I mentioned earlier and others as well. That being said, I and my peers at Cassandra Security stand in support of Rugged. Many of us have and continue to function in assessor & auditor capacities and understand all too well the flawed state of code in the world today through our own analysis and through the work of others. We believe in the concept and the goal. Do we believe that it will be adopted universally and that all software development flaws will be eliminated? No, we do not but we are hopeful that in encouraging the adoption and support of this ideal that we as professionals, as colleagues can encourage industry to address the points I made above and those contained within the body of The Rugged Software Initiative and Manifesto in order to mitigate the risk. Get Rugged, it might just save your life.
Accountability the Non-Negotiable Asset
In business, accountability is something that cannot be stressed enough. This was true before the economic breakdown of 2009, and will continue to be long after. Accountability is of paramount importance and perhaps more so than anything else, it is a good thing. Accountability is something that at some base level, all humans can relate to. Ask any child whether or not they receive reprimanding by their parents when found to be in violation of a rule and you will almost assuredly receive a response of ‘Yes’. If you receive a ‘No’ than perhaps, that is a sign of bigger challenges and problems to come. Regardless of the response, my belief is that you would be hard pressed to find anyone with any amount of intellectual honesty who would say that being accountable is a bad thing.
Accountability is a good thing. It is of imperative importance. Accountability aids us in the definition; maintenance and articulation of healthy boundaries that all humans need and require (though are not always seen or found present). Boundaries, rooted in the freedom afforded by accountability, enable us to live, grow and prosper with the understanding that we are all responsible for our actions (of course there are things which we cannot control however our responses to external stimuli as Marcus Aurelius taught us, are well within our sphere of influence). Accountability provides much more in the way of freedom than most would initially suspect.
As information security professionals, we should all (I will not assume that all do however, I will suggest that we all should), be cognizant of the value of accountability. If one looks at the continuum of information security, and its role within modern business today (regardless of the vertical or sector), one can conclude that being accountable should not be negotiable. We do not live in a perfect however and as a result, we must assume that in some organizations, for better or worse, it will be seen as being negotiable. In those cases where it is deemed negotiable, one need not look any further than to the leadership in place and their vision for both the culture. Similarly, in those environments where it is deemed unacceptable to be negotiable with respect to accountability one need not look any further than the organizational the leadership teams. When moral flexibility is allowed to negatively influence accountability, it should surprise no one when armies of auditors, assessors, consultants, vendors descend upon the environment in question to aid the bewildered, understaffed information security teams and management. There is blood in the water and sharks can smell it for miles off.
The impact upon the organizational culture, receptivity and tone becomes more pronounced as well. The cultural attitudes of the organization in question, in addition to the sub-cultures that exist within the primary organizations business units. Any number of scenarios can come about as a result from those that are extremely open, productive and collaborative to those that are terribly conflicted and shut down from a productivity perspective. Enterprises (whether in the public or private sector), do not need to settle for scenarios which encourage mediocrity and closed minded attitudes. The establishment of accountability as an elementary aspect of organizational culture and politics (social and / or formal), is a wonderful place to begin. This does not mean that organizations should begin encouraging Orwellian information gathering campaigns where rewards are given to those who inform on their co-workers infractions (real or perceived), but rather where all parties from within all roles understand their contribution to the organization in any and all forms to and including being accountable for ones’ own actions and to one another so as to prevent any damage to the organization and / its assets (tangible and intangible alike).
You might be saying to yourself as you read this “that sounds wonderful Will, however I live in the real world and work there to. I have no use for esoteric philosophical idealism when I need to get the job done today, especially when I have to demonstrate compliance for God knows what to God knows who”. Fair enough, I can appreciate that which is exactly why reply would go something like this “Of course you don’t, you’ve got a lot to accomplish in little time and with even less in the way of resources however if you take a few steps back from the situation, employing observing ego you will see that the advocacy of accountability in the form I am speaking of (predominantly through sound risk management based security programs and frameworks), would relieve you of much (not all), of the challenges you face”. Crazy you? Unrealistic? Immature? Handsome (had to throw that in to see if you were paying attention 
. My assertion is that through the adoption of a solidly crafted risk based security program and framework; accountability can be achieved where it currently does not exist and supported & enhanced where it already does so.
So how do we get there from here in the absence of accountability? The first step is to revisit your organizations P3 (process, procedure, and policy) to see what exists (if anything), to do date. Odds are, something does though the state and maturity might vary. Should you find yourself in a situation where you have none or what is roughly the equivalent of none, fear not. This is not necessarily disastrous however, it should be addressed and amended swiftly in order to ensure the organization maintains its risk posture or, at the very least, becomes cognizant of it.
The Payment Card Industry Data Security Standard (PCI DSS) is not the devil incarnate but comes under scrutiny (for good reason – a great deal of which has less to do with the standard itself and more to do with the organizations wrestling with it along with the credit card corporations themselves), likely as often as the devil himself. Before PCI was PCI, before there was this digital equivalent to “reefer madness”, where fear, uncertainty and doubt solely relegated to the world of the payment card and their affiliated merchants and provider – banking environments seemed to permeate every fiber of the tapestry of the Information Technology and Information Security worlds, all the bigs – Visa, MasterCard, American Express, Discover Card (aka Discover Financial Services), Diners Club and JCB International, all had their own ‘ways’ of assessing the security posture of their vendor / provider networks. Some were more inclusive and detailed than others. That is a fact.
It was ugly, it was cumbersome, it was ineffective and it warranted change as the credit card corporations and their affiliated banking partners were experiencing fraud and exploitation in a variety of ways from a variety of sources, which ultimately led to a convergence occurring within that world. A convergence which would have impact upon us all for years to come…like chocolate and peanut butter only not as good. Initially this did not seem like a bad thing. In fact, I happen to believe it was necessary in small scale to aid in jump starting awareness. I am proud to be personally acquainted with the primary architect of the original draft of the first PCI standard and know where his mindset was when he drafted it. I know his intentions were pure with respect to this standard. Furthermore, I also know that he did and does not believe the PCI DSS to be a legitimate replacement for sound risk management practice but rather a starting point for many organizations, which had no bearing point. Fair enough. I think we can all accept that, at least those of us who are intellectually honest. What happened? Why all the hub-bub? How did something which started out with solid intentions turn into this new and creative form of audit water torture which often yields little in the way of sound risk posture aside from gaining PCI accreditation…for what that is worth…I’m guessing the folks at Hannaford Supermarkets, Heartland Payments and Choicepoint (parts I & II) know what I’m talking about.
The PCI Standards are easily had these days as are lists of authorized assessors however, just because they are easily had (both the ‘standard’ and the assessors) does not mean they are effective. In many respects, PCI reminds me of the early days of HIPAA, the difference being that with PCI people actually being penalized for failing to comply. Sort of a novel idea really however I believe that that regulatory and auditing criteria (standards) – important as they are, in and of themselves do not meet the needs of enterprises small and large; private or public in our world today. What can meet these needs? (cue drum roll): Well designed business centric risk management security programs and frameworks. Are they trivial? No. No, they are not. However, neither is PCI, or HIPAA for that matter and whereas both PCI and HIPAA fall into the Sisyphean category in my view of the world, Risk Management does not, additionally, if undertaken risk management initiatives will provide an enterprise with a wealth of information which PCI never would (sorry guys), not on its best day. So the question (or one of them anyway), becomes: Why continue to divert time, effort, resources (personnel and budget), into something so one dimensional when a properly designed risk management based security program can address these and every other regulatory and compliance concern you’re presented with. The bit gods must be crazy…let’s read on.
I believe that the only way to rescue the hearts and minds (and ledger books!) of those responsible for budgets within industry is through demonstration of the intrinsic value of risk management (e.g. enterprise risk management, fiduciary risk management and information security risk management working in concert). This demonstration must be ubiquitous and comprehensive in scope to the enterprise in question touching all areas of the business: customers, business partners, P&L, revenue streams, brand preservation etc. This is something that I feel passionately about as do others within our industry. The fact is that as times and circumstances change (for better or worse), so too will budgets (for better or worse), and if initiatives such as PCI are not reconsidered (given the current volume of spend being seen as a direct result of meeting or achieving compliance with the standard) — in both scope and value, we may very well run the risk of encouraging and incurring new and previously unforeseen risk via new threat vectors previously not considered nor addressable due to a lack of budget (capital or operational), for investment in innovative technologies, processes and people.
