The following question, paraphrased, came up during my RSA 2013 presentation on why an Enterprise Information Security Architecture (EISA) matters:
Do you factor in threats when developing your EISA?
My initial response was essentially "no." The person who asked the question came up after the presentation and wanted me to think about that response.
Fair enough. I have been. Quite a bit.
I am going change my answer to "yes", but I want to qualify that a bit.
The primary qualification I want to make is scope. We need to be aware of the threat environment when designing our architectures, not necessarily the detail. While we need to understand the environment our enterprises are operating in from a broad perspective, we do not need to keep track of specific actors or threat actions at this level.
For example, when an architect is designing a building for an environment where tornadoes are common, he has to account for that in his design. However, he doesn't focus on architecting for a specific tornado. He can't.
Here's another example. If I am designing an EISA for a financial institution, being aware of the criminal element is important. Tracking exactly which group is using which malware is not, at this level.
I do want to make a huge plug for threat intelligence at the operational level though. Understanding who is operating against you, what they are doing, and the tools they are using is hugely valuable in tailoring our monitoring and response tooling.
So. Where does the threat environment information get captured?
In our context map. I didn't talk about context maps, and a whole bunch of other stuff, in my talk. I will be in future blog posts, but the short version is that the context map is a way to capture and represent the influences that make up the context our EISA will be developed in. "Understand the Business" is a big part of this context. Threat environment is another. There are many more influences.
So there it is. I flip-flopped.
What say you?
PS - To the person that asked the question, thank you!