Some say “timing is everything”, which I don’t necessarily agree with. It could sometimes make the difference between a useful effort or a wasted one, especially if it’s a business decision. In threat and risk assessment, you could also argue that if people are doing it early enough, it means they are designing for security and continually thinking about misuse cases and security issues that can occur in their environment, or with the product they’re building, in which case it’s clearly useful (you could change things around). If it’s done late, however, just because it’s a compliance requirement for instance, it’s potentially useless (and likely too late or too hard to change anything around).
In reality, though, it’s not that black or white. From a security planning perspective, both management and blue teams can still make good use of any form of risk assessment, no matter when it’s done. The worst-case scenario would be to accept all risks and plan for changes and improvements in capabilities and processes (and hope nothing happens in the meantime!).
A few years back, I wrote a blog post about a possible use case: using threat modeling as a way to help with prioritization in Vulnerability Management (VM). There is only a fraction of vulnerabilities that can ever be exploited, threat modeling would show how they can (realistically) be part of an exploitation, and those are the ones you should prioritize. It would be a baseline that can be used to prioritize and monitor vulnerabilities over time.
In theory, it’s a good idea to reduce noise (on both sides actually). in fact, both VM and threat modeling can be quite noisy and are going to throw at you lots of vulnerabilities, and ways your system can get breached (probably new ways and/or out of the norm). In practice, though, nobody does it. I haven’t seen VM folks using threat modeling to monitor risk associated with vulnerabilities and surface the most important ones (unless you consider CVSS rating as threat modeling, which is not!).
Because I mention both, let me just say that risk assessment and threat modeling are more or less the same thing for me, minus the level of detail you’re getting into. It’s a matter of the level of granularity at which you’re describing your risk and threats. The list of threats should be the same, except that threat modeling will require a more detailed understanding of the data and execution flows, as well as a detailed attack surface analysis, before technical threat scenarios and attack paths are drawn up.
Most use cases (in support of the “better late than never!”) come down to establishing priorities and/or better visibility around the attack surface. It can help achieve maturity in security controls, for instance, which is more or less the same as the VM use case, except that instead of prioritizing vulnerabilities, you’re making choices about what security controls would make the most sense given your posture (technically and from a compliance perspective). It can also help you build more resilient infrastructure, product, or service, or work towards more efficient processes for response and recovery. Things that are welcome at any time to identify gaps and help with priorities.
So it’s never a wasted effort, although it’s better done early (especially when you’re building a new product), and often. Small iterations, and varying levels of detail, are also fine. You don’t necessarily need a full-blown risk analysis of everything at once. There are no timing constraints, however, and there isn’t really a bad time to do it, provided it’s actually used afterwards to improve your posture and not only to comply with legislation or make an auditor happy!
