An excellent question - and one which goes to the essence of my talk! A surprising reality in information security is that a lot of activity takes place without a full analysis of your attackers' objectives.

The goals of attackers, their motivations, are varied: some may seek peer recognition or their 15 minutes of online fame; some are making a living selling private information or software exploits; others are acting out of loyalty to a greater cause, e.g. patriotism or affiliation with a movement.

The important thing to understand is that you're facing specifically motivated _human_ attackers, who (generally) will act in their best interests and have a cost-benefit model applying to their actions as well.

(As a side note, I actively try to avoid conflating the terms "hacker" and "attacker": "hackers" seek to fully understand a given system, modify it, change it, perhaps use it in novel or interesting ways. Their motivation is primarily intellectual. An "attacker", on the other hand, is pursuing a specific goal, using the most efficient methods at their disposal.)

Do hackers only attack through the web?

No. It's true that the web offers a large attack surface, often with a lot of low-hanging fruit such as XSS or command-injection vulnerabilities in popular frameworks. However, there are a myriad of different protocols spoken on the internet, each one offering a possible attack point.

What's more, "the web" means a wholly different thing today than it did just a few years ago: cloud services hosting distributed applications used by businesses and organizations around the world, accessed by mobile devices are far removed from the traditional client-server model of the HTTP world of the early 2000s.

In the end, a web service is only but one method of entering a system. Sufficiently motivated adversaries will find others up and down the application, network, organization, and social stack.

How is threat modeling more useful than following recommendations?

Perhaps one could say that a well defined threat model leads you to identify the guidelines you seek to implement; it provides the rationale for the recommendations.

Broad security recommendations, general guidelines, and industry best practices are useful to establish a bottom line. They allow you to implement general protection mechanisms when you don't fully understand the threat landscape.

Problems arise when these recommendations are followed blindly. Some recommendations also can have negative side effects, such as increasing operational costs. As a result, they may be applied inconsistently, with rules put in place that end up not making much sense.

Threat modeling, in brief, is the analysis of what exactly it is you're protecting and, importantly, from whom. It includes an assessment of your adversaries' skill set and motivations with respect to your own defense capabilities. It helps you determine which threats you can defend against as well as those you cannot.

An accurate threat model allows you to assess the attack surface, for example a given service and to determine effective, _specific_ defenses.

This may ultimately lead to recommendations and guidelines, but by applying a threat model, these rules become meaningful, precise.

Is this something that can be done with existing applications?

Performing a detailed, in-depth analysis of the risks a given service or organization faces is first and foremost an intellectual challenge. It requires an understanding of the threat landscape and an adversarial mindset.

In order to assess the set of realistic risks you are exposed to, together with your own means of defense, you need to have thorough knowledge of the applications in question. Some of this can be gained by running certain tools, but at the end of the day, you need to sit down with the subject matter experts to help you understand your application or service's trust boundaries, assumptions, and information flow.

This is best done early on in the development cycle -- security cannot be bolted on after the fact -- but a proper analysis of deployed service in production can be illuminating and helpful to understand the risks inherent therein.

Are there any tools or resources that can help companies with threat modeling?

As I mentioned above, this approach primarily relies on an in-depth understanding of both the technology stack and the social or organizational aspects in question; they require human intelligence and analysis.

The end result of this analysis may take a number of shapes: a written report, a collection of spreadsheets, information flow charts or diagrams, you name it.

Many of the standard tools used to perform penetration tests such as network and vulnerability scanners or data aggregation and processing utilities are helpful in the information gathering phase.

But unfortunately there is no simple tool that you can run against a service and have it spit out a threat model. So much in information security has to do with people and their respective motivations; each organization is different, has different assets that they assign different value to; each adversary may have different motivations and capabilities.

But in this variety also lies the most rewarding aspect of the threat modeling approach: it focuses on human and social aspects, and when done well, it can have a direct impact on your security posture. With an apt threat model, you can move the needle on your defense. That is what I hope to be able to present at the conference.