Intelligence Life Cycle-Requirements PDF

Intelligence Life Cycle-Requirements And welcome to the requirements and planning module in the Cyber Threat Intelligence Lifecycle course. I'm Sharon Fladograf and I'll be your instructor. The goal of this module is to provide students with an overview of how the initial phase of the intelligence c...

Intelligence Life Cycle-Requirements And welcome to the requirements and planning module in the Cyber Threat Intelligence Lifecycle course. I'm Sharon Fladograf and I'll be your instructor. The goal of this module is to provide students with an overview of how the initial phase of the intelligence cycle, namely the planning and requirements phase, is the step within the intelligence cycle where new intelligence requirements are generated and strategies for satisfying those requirements are planned. By the end of this module, students will gain an understanding of the importance of intelligence planning, be able to identify their key stakeholders, the types of intelligence requirements, and how to develop these requirements. We will be covering the importance of intelligence planning, understanding key stakeholders and mission parameters, and developing intelligence requirements. Then, I will walk you through a practical exercise on how to craft your own intelligence requirements. So let's dive in. Here's where we are in the intelligence life cycle. As the cycle itself is iterative, you can see that requirements and planning is both the first and the last step of the cycle. If you're starting from scratch, meaning you've been asked to stand up a new team or engage in something called threat-informed defense, which relies on a deep understanding of who your adversary is and how they operate to improve your cyber network defenses, then, of course, the first time you engage in requirements planning will be a bit more labor-intensive as you establish a baseline for your requirements. But once you start putting out intelligence products, you can't just rest on your laurels. You have to incorporate the feedback from your stakeholders and go back and refine your requirements or create new ones. Based on this, you can understand why the requirements and planning phase is used to establish mission scope and intelligence requirements, which will directly influence all other phases of the intelligence cycle. The mission scope is a statement of the parameters of a cyber threat intelligence program's area of responsibility. Intelligence requirements, or IRs, are the overarching analytic questions an intelligence team will attempt to answer through its products and services. Mission scope should generally remain static, while IRs should be adjusted regularly based on stakeholder feedback and periodic reviews. Intelligence plays a central role in planning and executing ongoing strategic and operational goals for an organization. By better understanding the obstacles, vulnerabilities, and threats presented to us, we can be confident that we are reaching informed conclusions about how to proceed and where to expend our resources. The process of generating a good intelligence product starts with sound planning. A vague or poorly defined mission or requirement will usually result in poor intelligence. Intelligence planning is the beginning and the end of the intelligence cycle. The beginning, because it involves drawing up specific collection requirements, and the end, because finished intelligence supports business decisions, which will then generate new intelligence requirements. During this phase, intelligence requirements are established, goals and objectives are set, and resources are allocated. But in order to gain a comprehensive understanding of the problem at hand, you're going to have to gather your squad, otherwise known as your stakeholders. Your squad should include personnel from different access points and interests within your company's network and business units. For instance, network operational centers or security operational center personnel, incident response personnel, chief information security officer, business security officers, and business unit managers from various units across your company. They will all have unique requirements based upon their access and relationship to the network and how they make market-facing decisions on behalf of your company's business strategies. During this phase, the intelligence team must also identify potential risks and threats that may impact the success of the intelligence effort. This requires a deep understanding of how your business operates, its attack surface, as well as an understanding of the capabilities and intentions of potential adversaries. Understanding who you are providing intelligence to and why you are providing it to them is the first step in sound intelligence planning. The universe of online threats is constantly growing, as are the available tools and techniques used by cyber adversaries. By seeking to answer key questions, threat intelligence can enhance the network defender's ability to employ their defenses in the most effective and efficient manner. However, if the analyst does not understand their organization's own network, then they cannot decide whether information is relevant or not. They can waste valuable time researching a threat actor or vulnerability only to find out that it doesn't affect their organization. Likewise, if the analyst does not know who their report is going to, they cannot tailor their intelligence, which could then be too technical or not technical enough. If the stakeholder cannot utilize the intelligence to help them prioritize their tasks or inform their decisions, then the intelligence analyst has failed to achieve their goal. You should remain flexible in your thinking throughout the planning process. Intelligence requirements can change rapidly based on evolving situations. Also, since the intelligence life cycle is an iterative process, as we mentioned before, you should expect to continually assess the effectiveness of the requirements and adjust as necessary. Periodic review will be necessary to update requirements and adapt to changing needs and environments. So, what is an intelligence requirement? Well, according to the dictionary, it is 1. Any subject, general or specific, upon which there is a need for the collection of information or the production of intelligence. 2. A requirement for intelligence to fill a gap in the command's knowledge or understanding of the operational environment or threat forces. The concept of intelligence requirements originated from the military, and while you won't be charging into battle, we can easily adapt its uses for the corporate environment. During the process of generating requirements, both intelligence analysts and their stakeholders should be encouraged to contribute. Each side of the process has a unique knowledge of the network and the threat landscape that may inform the other. Requirements can largely be generated by responses to the baseline assessment, although there is no time that requirements stop being generated. When standing up a threat intelligence program, this will generate many of the backbone requirements that will be periodically revisited. After prioritization of the assets has been completed, analysts that generate requirements may use a threat model as a starting point to determine what kinds of questions should be answered, such as the identities or class of potential adversaries, how adversaries are targeting the business's digital assets, potential vulnerabilities that are targeting critical network infrastructure, how the business risks present as cyber risks, for instance, bringing new business into a new country or region, or a merger, perhaps. There are two different levels of intelligence requirements. Priority intelligence requirements, PIRs, and intelligence requirements, IRs. PIRs are requirements that stem directly from the project planner. PIRs take priority because until they are answered, the project cannot move forward. Often, PIRs define the mission parameters and are the key analytic questions for which an intelligence team should be providing assessments or judgments to stakeholders. IRs are overarching requirements that are desired to support mission success. Often, they are strategic in nature and relate to longer-term routine aspects of business operation. However, there aren't hard and fast rules about the differences between IRs and PIRs. The terms are often used interchangeably. EEIs, or essential elements of information, are any critical intelligence information required by intelligence consumers to perform their mission. The EEIs are specific to a particular event, thing, or other target individuals. As such, EEIs fall under IR or PIRs. The EEI is written out in advance as a question by consumers of the EEI information. Then, the EEI questions are used by collectors of the information that may not be in direct contact with the consumer at the time the information is collected. A specific set of EEIs are used by collectors to develop a collection plan to find the answers to the questions in the EEIs. Collection requirements are statements of the types of information or data that should be collected to meet one or more of the EEIs. You will learn more about collection requirements in the next module. In the case of an intelligence requirement, you should adhere to several key principles. Clarity. Requirements must be specific and unambiguous to avoid misinterpretations. Relevance. They should align closely with the strategic objectives and operational needs. Prioritization. Determine which requirements are most critical and prioritize them accordingly. Just like writing work objectives, a best practice is to use the SMART formula. Your requirements should be specific, measurable, achievable, relevant, and time-bound. Let's write some intelligence requirements. Your chief information security officer, or CISO, has tapped you to start a cyber threat intelligence program. He tells you to just give him all the intel. This is kind of a vague request. Does he only care about threats targeting your specific company, your industry, your country? Is he talking about the threat actors themselves, the who, the campaigns, the what, or the attack techniques, the how, or maybe all three? After meeting with him to discuss your organization's priorities and business operations, you think you have a better idea about the type of information he's looking for. One priority for this year is that your company needs to provide some capabilities, like a call center, in several overseas locations, and they're not sure if they should outsource it or keep it in-house. So, our overarching collection requirement would be, what information do we have about outsourcing or third parties? That tells us that we have to start looking for resources and information about other companies who have outsourced similar capabilities and what their experiences have been so far, maybe what threats they have faced. Next, we have to define the question we are trying to answer. Outsourcing is a big topic. What specifically about outsourcing do we want to know? Well, for starters, we want to know about U.S. companies who have used third-party vendors overseas. We also want to know who is targeting the third-party dependencies. Now, under this IR, we can have several PIRs. For example, we want to know about the known threats to vendors and third-party providers used by American companies operating in Asia. Our second PIR could ask the same question, but for American companies operating in Europe, and so on and so forth. For every PIR, we then get really specific with EEIs. So, for our first EEI, we're going to ask threats to outsourced call centers that others in my industry are seeing. We could have a second EEI that asks the same question, but about outsourced operational centers as opposed to call centers. And again, these would all fall under for those American companies operating in Asia. For our second PIR, we would have similar EEIs specifically for Europe. It might seem tedious, but documenting everything out like this, you can clearly define what you are and are not responsible for investigating. In the future, you will start to see patterns where there are certain PIRs and EEIs that you can't answer. That will tell you where you have a collection gap and perhaps need to acquire new sources and visibility. Your requirements can also tell you what you aren't asking about, which might uncover something important that your stakeholders have overlooked. For example, your CISO wants to know about known threats, but what about emerging threats? What about the threat actors themselves behind the threats? Well, these questions might seem obvious and important to a threat intelligence analyst. They may not be so obvious to your stakeholders. It's your job as the intel analyst to draw out these details and guide your stakeholders to think about all possible scenarios. Here is a sample collection framework in Excel that we can use to document our previous example. Excel is a really good way to document out and have a record of all your PIRs and EEIs, and then it can be a shared document that your team can update periodically. We know that our overarching intelligence requirement is how are threat actors targeting American companies overseas via vendors and third-party dependencies? Our first priority intelligence requirement, or PIR1, is typed in the blue box. So, we would type in what are the known threats to vendors and third-party providers used by the American companies operating in Asia? From there, we enter our essential elements of information, or EEIs, in the green box. So, EEI 1.1 is are there any known threats, insider threats, or vulnerabilities involving outsourcing call centers in my industry? EEI 1.2 could be are there any known threats, insider threats, or vulnerabilities involving outsourcing operation centers in my industry? Now that we have our questions for each EEI, we have to decide how we will go about collecting the information that answers each question. Where will we find the answers? This will be covered in depth in the collection module, but examples include dark web sources, vendor reports, open source information, and malware analysis. Then, you notate down in the collection area what EEI is fulfilled by each type of collection. Once that is completed, we would start the exercise all over again with our second PIR, and so forth. This concludes the requirements and planning module. You should now have an understanding of the importance of intelligence planning, be able to identify key stakeholders, and the various types of requirements. You should also be ready to dive in and create your own collection management framework. Please complete the following post-lecture reading and podcast for additional insight into requirements and planning. The links to these resources are in your module folder. Information from these resources will be included on the final exam. To complete your required readings, you should start on your course assignment, which is detailed in the next video. If you have any questions about this topic, please feel free to contact me at the email on the screen. Thank you so much, and I hope you enjoyed your requirements and planning module.