#threatintel thread! For the past couple of weeks I've focused on #threatintel REQUIREMENTS. As a consultant working with clients to develop their programs, I focused on this a lot--requirements are important. As a full-time analyst, it's much harder: because OPS!
But, really honing-in on the requirements--the specific questions that customers have, the topics they are interested in, how they can best consume information--has been a valuable investment. Here's what I've learned or re-discovered...
For each requirement (or set of requirements), there is information you need to answer the question and a process to follow to fulfill the requirement. Sometimes you'll have the information you need; sometimes you won't which means that you have to go get it (collection).
You can find the information, buy it, or develop and engineer something to get it. On the process side, you may have no process, an immature process, or a mature process to fulfill the requirement.
So as an exercise, write down each requirement: *every* question or concern you've heard from your stakeholders. You may find patterns and like-groupings so: write it down, stare at it, think about it, revise, and repeat until you have a solid list. This process can take a while.
Remember: the question you ask shapes the answer you will get. (Asking: "what is the mass of sun?" yields a different answer than "how many earths can fit into the sun?" or, "how many times larger is the sun than the earth?")
For *each* requirement, document the information you have and what's missing. Next, think about the process you would follow to answer that question and write that down too. Some requirements may draw blanks on the collection and process side. That's good!
This will all probably feel mundane--its mostly documentation. Boring! Cool analysis is much more fun! But, what you're doing is starting to paint a picture of your entire intel program and capabilities. This is a valuable tool for your management and for YOU the analyst.
For management, you can now tell a story and support your argument for more resources: "Here's everything our stakeholders have asked us. We can reliably fulfill 30% of our reqs. We don't have information to answer X req., and we need processes for X reqs."
"To develop the process and capabilities for X req. it means we'll probably have less time to focus on Y reqs., but we have mature collection and processes around Z reqs., so we don't expect a decline in output against those."
You can also tell mgmt. the story over time: how new info., processes, or other capabilities allowed you to fulfill additional reqs; how other changes have left reqs un-answered, or how some reqs can no longer be met (e.g., "this log source broke," or, "an analyst left the team")
For you the analyst--no matter how cool the analysis is, it *has* to anchor back to the goals of the security program. If you'd done a good job of gathering requirements, those goals will be reflected in the questions you're trying to help answer.
You can also start to see how your analysis lines-up against the requirements. For bigger teams, I could see this enabling a good division of labor.
This concludes my thoughts on #threatintel requirements! Many folks smarter than me have written and talked about the importance of requirements and how to do them well, just wanted to share my experience over the past couple of weeks : )
Another thought on #threatintel requirements: once you know where your gaps in your ability to fulfill certain reqs exist, this becomes a great tool for PLANNING. Set plans to develop capabilities, build collection to meet reqs you currently aren’t able to answer.
This will give you more ammunition to tell the #threatintel program story to management.
