How to Define and Build an Effective Cyber Threat Intelligence Capability (2015)
Chapter 3. Defining Business Objectives or “Start with Why”
When it comes to “Why” start, build, plan, or even have a conversation about planning or building a threat-intelligence capability, it is important to start with “Why” at a business level. We cover the six macro-level reasons to build a cyber-threat capability.
Financial Institutions Examination Council (FFIEC) Guidelines
social media monitoring
open-source intelligence team
As mentioned earlier, most of the chapters in this book leverage a simple construct or sequence of “Why, What, How and Who”. In this case, when it comes to why start, build, plan or even have a conversation about planning or building a threat intelligence capability, it is important to start with “why” at a business level. If you belong to the nonprofit or governmental sectors, the term business objectives may not apply. You can, however, translate that to organizational objectives or agency mission. In other words, if you are part of a military unit, a nonprofit or a civilian agency, some of the “why’s” may be a little different than what you read here. For a commercial organization, though, there are really only six macro-level reasons to do anything.
1. Growing revenue, or the margin on the revenue you have already have
2. Lowering expenses
3. Reducing business risk
4. Increasing customer satisfaction and retention, which eventually should translate to more revenue or more margin, but which are worthwhile objectives in their own right
5. Increasing employee retention and satisfaction, which eventually should translate to lower expenses, but which are again worthwhile objectives in their own right
6. Complying with regulations or over governmental mandate, that is, “because you just have to”
At the executive management, top floor, corner office level, these are the only six reasons to organizationally bother with the effort, expenditure, and disruption of doing anything, especially something new. That has to be the “why” with which defining and building a threat intelligence capability must align.
3.1. When defining business objectives, language matters
Language matters. The translation from security or intelligence to a perspective that matters to management is a critical step in both the planning and ongoing operations process, and one where security and intelligence professionals sometimes hit some stumbling blocks because they do not have the “interpreter” with the language skills to make that jump. Teams will sometimes employ a dozen very smart people who read raw source code and speak binary, but none who speak “management”. Although some do not believe in its power, the translation is going to be very important in both directions.
The words that you choose as a security or risk professional to translate the threat intelligence initiative or request funds for ongoing operations to the management level must be according to the language of the business or organizational mission. It is vital to understand how you can align the threat intelligence group, department, or center’s mission with that of the organization and communicate the budget requests, required resources and so forth in the language that management speaks, rather than in the language security professionals speak.
Any organization large enough to be looking at a dedicated intelligence capability – whether through supporting vendors, in-house staff and resources, some hybrid model between the two – should be able to translate that back to the organization’s objectives because that is the best, indeed the only way, to ensure the support and resources you will need. Put simply, nothing happens without money. As blunt as that may sound, it is the truth. If you cannot tell the folks with the money why they should give it to you in words and objectives that matter to them (not what matters to you), your effort is likely to be short lived at best.
So before you buy one bit of data, one tool, one data feed or even let a vendor into your office to consider their offerings, sit down and talk with your team. In the case of Cyveillance, they offer a simple checklist. Before reviewing or spending anything, it is important to ask a number of questions internally, and investigating these more deeply will constitute the bulk of this book. But for now, let us set the stage at a high level.
First: What business driver are we in alignment with to buy or build some kind of threat intelligence capability? Are we doing this to meet a compliance requirement? For example, if you are in the financial services industry, you will need to address the recent FFIEC guidelines that were finalized around social media and online monitoring. That is a perfectly valid reason to say, I am going to go out and get some “intelligence” around what is being said online. I have a regulatory requirement and that could be part of the mission of my cyber center. Is it to reduce risk, to be aware of other things that will help you prevent a data breach, things that will help me respond to or discover if a breach has already happened? All laudable goals so long as you can align them explicitly to reducing risk, reducing expenses, or other managerial priorities.
Now there are people who may have other motives. For instance, some people have contracted professionals for the task of building out this capability or pricing out an initial budget request because an executive heard the words “threat intelligence” hundreds of times at a big conference and just realized that it is actually a “thing”. Although this is in no way a good reason to look at threat intelligence, it is one that threat intelligence experts are bound to come across.
Another important question is: Will you be able to define a clear and bounded set of mission responsibilities in support of that business objective? This is important because, in large organizations, word will quickly spread that there is a team of “cyber experts” being stood up. The day this happens, you may find everyone from attorneys with their trademark and brand issues, to the compliance officer to the marketing department running to see if they can offload some of their work on you under the rubric of “monitoring the Internet” or “online intelligence.” The minute that folks hear that such a structure is underway, they will eagerly seek to hand over some of their work, and let you spend your people and budget doing something they have been doing (or not doing).
This is why a bounded set of responsibilities as well as a portfolio of activities in alignment with that business driver is important. Although your team may well wish to be of help to the counsel’s office on domain name issues or marketing on “buzz metrics” or the compliance group on watching for employees blabbing about confidential deals on their Facebook page, if those activities are not in support of the bounded scope and mission that your team can point to as components of their priority list, they will easily become overwhelmed or distracted. Applying the limited capacity to the right activities will be a key to success.
Equally important is this: Can you quantify the problem, the risk or at least the value of solving the problem in any way? Suppose, for example, one year into your intelligence program, nothing bad or scary has happened. Is that because luck was on your side? Or is there any indication that your efforts contributed to that positive outcome? Metrics that are meaningful for reporting and measuring contribution will be very helpful as you progress.
Next, do you have some kind of operational model or architecture that will allow you to ingest, generate, produce, purchase or otherwise beg, borrow or steal the information that becomes intelligence in support of those business goals? What is that operational model? In other words, if you had your people and your budget in place tomorrow and were all set to start building your threat center, do you yet have any idea how you will implement the process? In simple terms, will you plug this data or that cable into that box over there and put it in front of this person in order to make something useful happen? If you do not yet know the implementation or infrastructure approach, it is probably too early to discuss many types of vendors and services. Note that you will also urgently need the participation and support of your IT, networking, or other operations type departments. Many a threat center has been delayed or derailed the moment a plan or design lands in IT and someone says “you are not putting that on my network.”
And, finally, if all of that infrastructure was actually running today, how would you report and measure performance to justify both the initial and ongoing running costs of doing this? What would you share with management each week or month or quarter to demonstrate not just activity but also value and benefit. Activity for its own sake without business value is called “an opportunity to cut costs next year.”
To sum up then, if you cannot answer these five questions, at least preliminarily, stop. You are not ready to buy anything, except perhaps some consulting or professional services to help you answer them before you proceed.
1. What is the driver to buy or build threat intelligence capabilities? Compliance? Risk reduction? Someone just got back from RSA?
2. Can you define a clear, and bounded, mission or set of responsibilities?
3. Can you quantify the problem, the risk, or the value of the solution?
4. How will you operationalize the information to support the objective?
5. How will you report and measure performance to justify expenditures?
For many organizations, there actually is a justification to do a great deal of work and investment around threat intelligence; but in order to proceed intelligently and effectively from a business standpoint, you should at least begin to sketch out answers to these questions. How to do that will be covered in the upcoming chapters.