NTU Cyber Threat Intelligence Lifecycle Production PDF

NTU Cyber Threat Intelligence Lifecycle Production Welcome to the NTU Cyber Threat Intelligence Lifecycle Course Production Module. My name is Chris Carston and I will be your instructor for this module. This module will cover the fundamentals of intelligence production with the goal of providing st...

NTU Cyber Threat Intelligence Lifecycle Production Welcome to the NTU Cyber Threat Intelligence Lifecycle Course Production Module. My name is Chris Carston and I will be your instructor for this module. This module will cover the fundamentals of intelligence production with the goal of providing students with a better understanding of why we develop intelligence products and what makes an intelligence product different from other modes of communication. First, we'll start with a brief introduction to set the stage. Then we'll discuss the importance of intelligence production, particularly as it relates to supporting stakeholders. Next, we'll consider the thresholds and triggers for initiating the production process. We'll also discuss the different types of intelligence products a CTI team might produce and how to develop product lines to appropriately capture and brand these different product types. Finally, we'll explore some production best practices and consider how these elements fit together into a production process. Begin this module with a recap of the intelligence lifecycle. The intelligence lifecycle describes five distinct phases of the end-to-end intelligence process, which we use as an overarching framework for organizing the core workflows of a cyber threat intelligence team. The requirements and planning phase includes all the workflows associated with the intelligence requirements and collection management processes, which set the foundation for the subsequent phases of the intelligence cycle. The collection phase focuses on the processes and approaches used to collect information and data that will be analyzed and leveraged to produce intelligence products. The processing and ingestion phase relates to the tools and models used to ensure that the information and data we have collected are in a format that is appropriate for a team's analytic tools and processes. The analysis and production phase focuses on the analysis of the data and information we have collected to derive analytic assessments and judgments, which are then developed into intelligence products intended to support stakeholder action and decision. This course has separated the analysis and production phase into two distinct modules, one for analysis and one for production. You should have already taken the analysis module as this module focuses exclusively on the production component of this phase. If you have not already done so, please pause this module and review the analysis module first. Lastly, the dissemination and feedback phase includes all the processes and workflows associated with delivering intelligence products to stakeholders and soliciting feedback to refine our intelligence requirements and our overall end-to-end intelligence processes. A moment to consider how production fits into the overarching goals of the intelligence lifecycle. When we think about intelligence as a discipline, it's important to remember that it's inherently communications focused discipline, and cyber threat intelligence is no exception. All of the work performed up to this point, as detailed through the other phases of the intelligence cycle, are undertaken to allow us to communicate our analysis, judgments, and findings to our stakeholders. That said, the communication of this analysis to stakeholders is collectively referred to as production, and each individual report created by an intelligence team is referred to as a product. In the cyber threat intelligence space, products usually take on a few forms. Finished intelligence, or Fintel, which resembles traditional intelligence products and are usually developed to enable prioritization and decision-making around network defenses and architecture. Technical intelligence products, which more closely resemble technical reports such as forensic analysis reports or diagnostic reports, and are usually developed to support cybersecurity practitioners conduct specific actions such as threat hunting, incident response, or detections engineering. And lastly, intelligence briefings, which are usually intended to support senior stakeholders or intelligence-adjacent cybersecurity initiatives, such as training, exercises, or partnership engagements. For the purposes of this module, we'll largely focus on best practices around finished intelligence production, as these principles are somewhat universal and can be applied to products of all formats and for all stakeholders. First, let's take a step back for a moment and discuss why we're producing intelligence products in the first place. Essentially, it's a matter of effective and fit-for-purpose communication between two parties, the intelligence analyst and the stakeholder. The graphic you see on the screen is a basic communications model, commonly referred to as SRAM's model of communication. In this model, we see communication between two parties, which we'll refer to as the sender and the receiver. The first step is interpretation by the sender, which is the thought, idea, or observation that the sender wishes to communicate to the receiver. The sender then encodes their thoughts or ideas into a message using symbols, language, or other forms of communication. The message is then sent to the receiver, who must decode the message and then interpret its meaning. However, if the receiver is unable to decode and appropriately interpret the message, then effective communication has not occurred. This is why the preciseness of the message, our intelligence product, is paramount to the entire intelligence lifecycle. If we are unable to effectively communicate our analysis, judgments, and findings to our stakeholders in a way that they can understand and act upon, then we have failed in our goal as intelligence professionals. As one researcher put it, if you are unable to clearly communicate the results of all the research, analysis, and other grunt work that you have put in, then, from the reader's viewpoint, none of that mattered. What the production process does is ensure that we are following best practices to consistently and effectively communicate our analysis, judgments, and findings to stakeholders to ensure that they are able to understand and take action based on these findings. Now that we've established the need for effective communication, let's discuss what makes communication successful from an intelligence standpoint. To do so, let's briefly revisit and deconstruct a quote discussed in the introductory model. It reads, Reduced to its simplest terms, intelligence is knowledge and foreknowledge of the world around us, the prelude to decision and action by policymakers. This quote is attributed to the U.S. Central Intelligence Agency and highlights a core concept that we'll return to throughout the module. At its core, intelligence is a stakeholder-focused endeavor, and intelligence products must be developed with the intent of enabling stakeholders to make decisions or take actions, a concept often referred to as actionability. To ensure our products are actionable, we need to put our stakeholders at the forefront of the production process. Some questions we might ask ourselves are, who are the primary stakeholders for this product? What do those stakeholders have control over from a decision and action standpoint? What level of technical detail is appropriate for this stakeholder? How quickly do they need to make a decision or take action based on the judgments and findings in the product? What types of assessments or key pieces of intelligence would be most useful in reducing uncertainty around this issue? By considering the needs of the stakeholder, we can better formulate intelligence products that will be actionable and appropriate for our audience. As we move on to the more practical applications of this module, you'll find that the needs of the stakeholder are at the forefront of every step of the production process. The first issue we need to consider is when to create a product and when not to. Remember, intelligence is a functional form of communication. Unlike news or current events communications, which are often produced to inform and in some cases entertain, intelligence products should have a purpose beyond simply notifying stakeholders of an issue or an event. To explore this concept, we'll use a model based on traditional intelligence tradecraft that has been modified to apply to the CTI field, which we call the CAN model. The CAN model allows the CTI analyst to quickly assess whether or not an issue or event meets a minimum threshold to initiate production based on four basic questions. Is the issue or event cyber threat related? Does the analysis of the issue or event answer an intelligence requirement? Are there probable analytic findings or judgments related to the issue or event that will be actionable by stakeholders? And is the issue or event new or is there a development related to it that is of probable current interest? One caveat to mention before we dive deeper into this model is that it was developed to apply to teams that have a traditional CTI mission space. In other words, a specific focus on threats to IT systems and infrastructure. Some organizations may also require their CTI teams to conduct analysis outside of the threat space or conduct research on non-cyber issues. In this case, the model would need to be modified to align with that expanded mission space. Starting with the first question, is the issue or event cyber threat related? Essentially, we need to establish that the issue or event in question is a probable cyber threat to our organization. To explore this, let's consider the following scenario. A cybersecurity news organization publishes an article highlighting an emerging campaign in which the threat actors are exploiting a zero-day vulnerability in a popular file transfer application. The campaign appears to be exclusively focused on the national government of the country where your company is located. Whether or not this is a probable threat to your organization depends on a few factors. The most obvious one for this scenario is whether or not your organization uses the affected file transfer application. If not, then your team probably shouldn't develop a product about it because there's no decision or action that need to be taken by your stakeholders. Another issue to consider in this scenario is victimology. The campaign appears to be focused on the national government. So if you work for a marketing firm, the threat associated with this campaign to your organization is probably low based on current intelligence. Continuing with this example, let's say another article comes out that attributes that campaign to the military of a neighboring country. The article suggests that the neighboring country is also building up troops along the border of your country. Should you write about it now? One issue to consider is whether or not you're veering into geopolitical or military analysis. Obviously, a war with a neighboring country is likely to heighten the cyber threat environment in general, but is anybody on your team qualified to determine whether or not a conflict is likely? Do you have the intelligence or tools to make such an assessment? If not, you should probably avoid production on this topic unless directly asked to do so by stakeholders. Lastly, let's consider the scenario from another angle. One way organizations might approach this problem is to shore up defenses more generally in advance of a potential conflict with the neighboring country. A colleague suggests to you that you look at all the critical vulnerabilities present in your environment and produce a risk assessment and remediation plan. While this might be a value to your organization, the issue here is that this is not a threat related workflow. With this in mind, it's important to consider whether or not the issue you're working on is veering into risk or vulnerability analysis, which are separate disciplines that require specific tools, skill sets, and models that are not commonly used by CTI teams. Next, let's consider whether or not an issue or event meets an intelligence requirement or IR. As you've learned in previous modules, IRs are formal statements of intelligence needs that are generally developed with input from stakeholders and form the foundations of a CTI program. It's important to remember that IRs can be standing, ad hoc, or even implied. Standing IRs are what we generally think of when we discuss IRs. They are the core IRs of your program that have been formally agreed upon by stakeholders. Ad hoc requirements are those developed in response to specific situations or events. For example, an ad hoc requirement might come in the form of an email from your CISO. Lastly, implied IRs are those that an analyst may determine are or should be of interest to your stakeholders even if they haven't been formally or directly requested. For example, let's say you learn about a cyber attack that impacts a technology startup that your company is considering acquiring. Even if you have no formal requirements related to this issue, you may want to consider developing a product on it regardless due to the implied relevance to your organization. Ultimately, the reason a CTI team will want to rely on their IRs to guide production is to avoid chasing the cyber news cycle and to avoid becoming a cyber research team. The cybersecurity space moves quickly and there will be new incidents, events, developments, and emerging technologies discussed in the news and open sources on a day-to-day basis. But your job as an intelligence analyst is to separate the signal from the noise to ensure that you are only highlighting issues that are the most relevant and actionable to your stakeholders. This way, when stakeholders receive an intelligence product, they know it's something they need to pay attention to and act upon. If a CTI team attempts to report on everything, their stakeholders will quickly experience information fatigue and may not pay attention to the truly important products produced by that team. Next, let's discuss actionability. As mentioned earlier, a question we might ask is can I develop a product with the information, insights, and context needed to enable my stakeholders to act or make decisions in response to this issue or event? Let's consider the scenario we discussed a few moments ago, an emerging campaign in which the threat actors are exploiting a zero-day vulnerability in a popular file transfer application. Let's say your organization uses this application and is in the same industry vertical as other victims. There's an obvious cyber threat here because you use the application and are within the victimology. It very likely answers an IR for the same reasons. So how do we make an actionable product? Let's consider the mission and authorities of our stakeholders. Who in our organization is in a position to potentially do something about this? In this case, our primary stakeholders might be the team that manages vulnerability patching. They'll likely need context to help them prioritize and remediate this vulnerability. A secondary set of stakeholders might be the incident response team, which will need to conduct threat hunts to determine whether or not the organization has already been impacted by the campaign. Similarly, they'll likely need context around exploitation of the vulnerability. This suggests that we should develop a product with analysis and findings around the criticality of the vulnerability, how it's exploited, insights on technical remediations or patches available from the developer, and indicators of compromise associated with exploitation. Lastly, we need to consider the level of detail required for the product to be actionable for these stakeholders. Since we're dealing with working-level network defenders, this product will probably need to be relatively technical and include specific operational details about the vulnerability and campaign, if available. Finally, we'll need to consider whether or not this issue is actually a new development that requires an intelligence product. It's important to remember that intelligence is inherently a forward-looking and action- oriented discipline. This means that historical issues or those overcome by other events are generally not going to be in scope for a CTI team unless it has some direct relevance to the present or future threat landscape. As a rule of thumb, CTI teams should only create products focusing on recent or developing incidents, threats, or technologies. For example, if the U.S. government declassifies a report about a Russia Nexus cyber intrusion that affected an electric power provider in 2010, the report may receive significant media coverage and be discussed in the context of current events. But does it have any current intelligence value? Any threat actor infrastructure or observables discussed in the report are almost certainly too dated to be of intelligence value, and if the tactics, techniques, and procedures discussed in the report are not novel or have been observed in other reporting more recently, then it probably doesn't warrant an intelligence product. Similarly, it's important to consider whether or not the intelligence has already been actioned by your stakeholders. For example, let's say an intelligence partner shares a confidential report with your team about an unspecified incident impacting an organization similar to yours. So, you produce a product about it for your organization, and your engineering team remediates the issues that led to the incident. Several months later, a major cybersecurity vendor publishes a report about a campaign that you learn is the same one that impacted the previously mentioned organization. Since your organization already took actions against this threat, if there's no novel intelligence in the vendor report, you probably shouldn't create another product. In summary, the CAM model allows the CTI analyst to assess whether or not an issue or event meets a minimum threshold to initiate production based on a few general rules of thumb. Ultimately, our goal with this exercise is to ensure that we're developing products that are both actionable and appropriate for our stakeholders. Now that we've established some thresholds for initiating production, we need to consider the types of products a team might produce and the differences between them. Intelligence products are generally grouped into three major categories. Strategic, operational, and tactical. Strategic products usually cover broad topics, are more in- depth, and are generally intended to support strategic or long-term decision-making, investment, or organizational changes. As a result, these types of products are usually intended for senior policymakers and other stakeholders in leadership positions. However, there are instances in which strategic products are more appropriate for working-level cybersecurity practitioners. Because of their strategic nature, the issues or events discussed in strategic products are generally those that may impact an organization in the future, usually several months, if not years beyond publication. Because long-term investment or organizational changes may take time to implement, actionable strategic intelligence products need to be developed with longer lead times in mind. For example, if you worked for a technology company located in a country that was experiencing escalating tensions with a neighboring country, you might consider writing a strategic intelligence product about the cyber threats associated with the neighboring country. Such a product might include recommendations on long-term investments in security solutions and personnel that would likely mitigate or reduce those threats. However, this type of product may need to be published before the onset of any conflict to allow time for investment and recruitment. Strategic products may include technical details, discuss issues from a non-technical perspective, or include both to appeal to different stakeholders. Using the same example mentioned above, a strategic product on the cyber threat posed by a neighboring country might include non-technical information such as the country's overall cyber strategy or key industry verticals that it tends to target, as well as a technical annex that includes detection rules and indicators of compromise. Operational intelligence products usually cover relatively more specific issues than strategic products, such as a named threat actor or an emergent campaign, and are usually shorter in length and contain fewer details than strategic products. As the name implies, these types of products are usually intended to support operational actions or programmatic decisions associated with network defense and operations. As a result, these types of products are usually intended to support mid-level stakeholders such as program managers, team leads, and incident commanders. These types of stakeholders require intelligence that will assist them in prioritizing threats, instituting changes to processes or playbooks, and incorporating technical indicators or behavioral signatures into security tools and architecture. This suggests a focus on issues or events that have moderate lead times to potential impact or crystallization, usually weeks or months from the time of publication. To provide an example, if a CTI team collects intelligence on an emerging but not fully operational ransomware team that is recruiting individuals with experience operating voice and text- based phishing schemes, they may want to consider developing an operational product that includes recommendations for detecting and mitigating voice and text-based phishing. This would allow incident response managers to update and test email detection tools for potential phishing emails that contain callback numbers, incorporate these types of threats into phishing simulations, or temporarily shift incident response resources to text-based alerts. Due to the audience, operational products are generally more technical in nature since they are intended to be used by subject matter experts and must include enough technical details to support operational changes. Tactical products generally focus on individual issues or events, such as a specific threat, incident, or vulnerability, and usually cover only the most critical details needed to allow stakeholders to rapidly interpret and act on their findings. Tactical products are usually created to directly support incident response activities and therefore are usually intended for working-level cybersecurity practitioners who are directly conducting investigations, responding to alerts, or remediating issues, sometimes referred to as hands-on keyboard network defenders. These types of products usually deal with issues that require immediate attention or have relatively short lead times to potential impact, usually only a matter of hours or days. Because of the more immediate nature of these types of products, any recommendations or applied actions and decisions should be associated with business-as-usual workflows or something that can be implemented relatively quickly and with minimal investment or approvals. As you might expect, given the audience, these types of products are usually the most technical because they are intended for action by working-level subject matter experts who need to understand the technical aspects of a threat to directly respond to it. To provide an example, a tactical product might be one produced to inform network defenders of a critical vulnerability being exploited in the wild that includes details on behaviors associated with exploitation and indicators of compromise. This type of product would allow network defenders to set alerts, conduct threat hunts, and initiate incident response playbooks. Ultimately, the issue or event that is the subject of an intelligence product, particularly its lead time to impact, level of seniority required for approvals to conduct threat mitigation, will primarily drive the type of product produced. That being said, the vast majority of products that most CTI teams produce will be operational or tactical products that support network defenders and their team leads. These types of products are often referred to collectively as current products or simply current because they generally deal with issues that have recently materialized, have relatively short lead times to impact, and usually require action or decision from stakeholders in the near term. Now that we've discussed the different types of intelligence products a CTI team might produce specifically to account for target stakeholders, levels of technical detail, and likely actions or decisions, let's discuss how we subtly communicate those concepts to our stakeholders through product lines. To explore this idea, we'll use a basic concept related to marketing and branding. Consider a large beverage manufacturer and how they brand and market their products to customers. All of the products you see here are produced by the same company. They sell a wide range of beverages that include many different types of soft drinks, juices, waters, and sports drinks. However, they don't brand each individual drink separately. Rather, they create groups of products called product lines that are similar in nature, have similar branding, and are generally marketed to the same sets of customers. To illustrate this point, let's consider a specific product line produced by this company. All of the beverages in this product line are sports drinks. The products all have similar labeling and branding, and the product line is generally marketed to customers who are athletes or fitness enthusiasts. So when a customer goes into a store that sells beverages and sees a beverage that has this branding, the customer immediately recognizes that it's a sports drink. If the same customer just played a sport or went to the gym, they might consider purchasing this product due to its marketing and branding to athletes. In other words, even if a customer has never purchased one of these beverages, they probably have a good idea of what the product is and whether or not it's relevant to them based on the product line. As it relates to intelligence, product lines function in a similar way. Intelligence product lines are developed with specific branding, formatting, and style to communicate a specific purpose and audience for those products. Usually, teams create different strategic, operational, or tactical product lines, but they may also create product lines that include multiple product types. A good example would be a current product line, which, as we learned a few moments ago, may include both operational and tactical products. To provide a tangible example, let's say your team creates a current product line called the Cyber Threat Insight, which is generally intended for cybersecurity practitioners with the purpose of enabling them to take actions or make decisions about emerging threats to your organization. Similar to the sports drink analogy, once your stakeholders become familiar with this product line, they will have a good idea of what type of intelligence they can expect to see in a Cyber Threat Insight. So when your team disseminates one of these products, stakeholders will be able to immediately recognize whether or not they're the likely target audience. In this case, when you disseminate a Cyber Threat Insight, incident responders will recognize that they are the intended audience and will likely need to take action or make decisions based on the product. In other words, product lines allow you to quickly communicate to your audience about the type of intelligence, the level of technical detail, and the probable applications of the product before they even read it. This ensures that your product receives the appropriate level of intention from your primary stakeholders while also telegraphing what they should expect to see from the product. Now that we've explored product lines, let's discuss some best practices for product development, starting with product format. As we've discussed, intelligence products should communicate insights and context on complex and often technical topics in the shortest amount of time possible. Remember, we're often dealing with stakeholders who have limited time and are overwhelmed with other tasks and information sources. The job of the intelligence analyst is to cut through that noise and provide clear, concise analysis and judgments that allow stakeholders to quickly take actions or make decisions. This is why formatting is important. Effective formatting allows us to communicate significant amounts of information in the most concise way possible. To do this, let's look at a sample intelligence product developed by MasterCard to illustrate some of these concepts. First, you'll notice that the name of the product line and the date of the publication are at the top of the page and readily visible. The reason we put this information at the top isn't just for branding purposes. As we've learned, the name of the product line immediately communicates the type of intelligence, the primary audience, and the probable applications of the intelligence to the reader, while the date communicates the relative newness of the intelligence contained in the product. A reader can therefore immediately tell if the product is likely intended for them and if it's been published recently enough to likely still be actionable. Next, we include any sharing restrictions we might have for the product. In this case, using the Traffic Light Protocol, a sharing classification system commonly used in the cybersecurity community. This communicates to the reader up front about restrictions they need to be aware of before forwarding or sharing the product with other individuals or organizations. Now let's take a look at the title. The title of an intelligence product should be analytic in nature and summarize the key takeaway of the product. A reader should be able to look at the title and immediately understand whether or not the product is likely of interest to them and whether or not they may need to take actions based on it. Next, you'll see that this product includes a summary paragraph. While some products may not require this, particularly if they're under a page in length, including a summary paragraph is generally recommended even if it's only a sentence. The summary should be a concise overview of the key findings of the product and for some readers, particularly those who are not the primary audience members, this may be enough for them to get the basic gist of the product without having to read the entire piece. For the primary audience, who should read the entire piece, the summary communicates up front the main points that they need to focus on as they read the product. As we get into the body of the product, you'll notice that each section has a lead paragraph consisting of one or two sentences followed by several bullet points. The paragraphs contain our assessments or judgments and are therefore analytic in nature, while the bullet points provide the key supporting evidence and context for those judgments and are generally factual in nature. To provide a simple example, an analytic judgment in a lead paragraph might read, it is likely to rain this afternoon. The supporting bullets might be the reported dew point, which is the temperature at which water vapor begins to condense into liquid, was reported to be 55 degrees Fahrenheit today, and the temperature is reported to drop below 55 degrees Fahrenheit no later than 3 p.m. this afternoon. This format allows the reader to follow the logic of our assessments while also communicating important context for the reader. Next, you'll see that we've separated major analytic judgments into different sections following the same format. This allows readers to digest one or two key judgments at a time and also allows us to separate key pieces of factual information or data into appropriate sections to avoid overwhelming readers with a data dump. So, just to recap, we use well-thought-out product formatting to communicate lots of information in a short amount of space. This ensures that we're minimizing the time and effort required by our stakeholders to understand the relevance, key takeaways, and critical context contained within the product. Now that we've learned how intelligence products are conceptualized and formatted to maximize the efficiency and effectiveness of intelligence communications, let's briefly discuss the fundamentals of intelligence writing. To do this, we'll examine some language and stylistic choices found in a typical intelligence product. Specifically, we'll be looking at a national intelligence estimate published by the U.S. intelligence community, which is available online. A national intelligence estimate is a strategic product that is intended for senior policymakers, many of whom are unlikely to be subject matter experts in all or most of the topics covered in any given product. The goal of the national intelligence estimate is to communicate high-level strategic judgments about key U.S. national security issues and is intended to inform policymaker discussions and decisions around U.S. foreign policy topics. So, let's examine some of the writing best practices we can observe in this short example. First and foremost, the product presents the most critical judgments immediately, a practice commonly referred to in the intelligence world as putting the bottom line up front, or bluff. This is one of the most common and effective practices for intelligence writing because it allows the reader to understand the crux of the product immediately without having to search for or speculate on key findings. Next, you'll note that the product is written in active voice. Active voice is when the subject of a sentence performs the action. For example, in the sentence, the chef cooked dinner, the subject, the chef, is doing the action, cooking. In contrast, passive voice occurs when the subject receives the action, such as in dinner was cooked by the chef. Here, the subject is now dinner and is being acted upon by the chef. Another example of passive voice is the sentence dinner was cooked, where dinner is still the subject and has been acted upon, but there is no specific actor named doing the cooking. Intelligence writing stresses the use of active voice because it promotes clarity, precision, and conciseness. In active voice, the subject of the sentence directly performs the action, which makes the writing clearer and easier to understand. This is crucial in intelligence production where information must be communicated efficiently and without ambiguity. In contrast, passive voice can obscure the actor or cause of an event, making the information less direct or more ambiguous. Active voice helps highlight key details, responsibility, and action, which are all essential to conveying intelligence findings. Another key distinction of intelligence writing is the use of probabilistic language in sentences that convey analytic assessments or judgments. Probabilistic language is the use of qualifying adverbs such as probably, very likely, or almost certainly that are used to convey the relative level of certainty or uncertainty we have in our judgments. This is an essential practice in intelligence writing because intelligence analysts often need to provide judgments about events that have not yet occurred or on topics for which there is limited or incomplete information. The use of this language conveys the relative likelihood of the judgment to stakeholders, which may directly inform their decision-making process. A related concept is the use of confidence statements, which provide additional context on how confident an analyst is in their judgment based on the strength of the underlying information supporting that judgment. Next, you'll note that the product spells out acronyms and explains technical terms, as well as provide specific dates, figures, and other key contextual information wherever possible. Both of these stylistic choices are included to ensure clarity and reduce ambiguity for the reader. When we think about acronyms and technical terms, it's important to remember that some of our stakeholders are unlikely to be subject matter experts on the specific topic of the product, and it is our job to make sure that the language is clear and accessible. Similarly, including specific contextual information, such as dates and figures, ensures that our stakeholders are not misinterpreting key pieces of information. For example, if we write, threat actors are likely to begin widespread active exploitation of this vulnerability in the near term, near term can be interpreted in many ways as hours, days, or even weeks. If what we're actually assessing is that threat actors are likely to begin exploitation of this vulnerability in a matter of hours, and therefore defensive action should be conducted as soon as possible, adding a specific timeframe conveys this more clearly. For example, threat actors are likely to begin widespread active exploitation of this vulnerability within hours, and initial reports of victims being impacted have already been observed, provides a much more precise and actionable assessment. Lastly, it's important to note that intelligence writing needs to have a consistent style and organizational voice. Most CTI teams manage consistency by using common taxonomies, such as the MITRE ATT&CK framework or describing threat actor behavior by maintaining what's called a style guide to document how analysts should write common terms or ideas. For example, there are a number of ways an analyst could describe the initial stages of an incident, including gaining a foothold, breaching the environment, or compromising the network, but MITRE ATT&CK uses the specific term initial access to describe this tactic. So a CTI team that uses MITRE ATT&CK in their products will consistently refer to the early stages of an incident as initial access, which reduces ambiguity for readers. Finally, organizational voice refers to the concept that every intelligence product should sound like it was written by the same person. This is because intelligence products are not the judgments of any individual analyst, but those of an entire team or even an organization, and the writing style should reflect this. To accomplish this, many teams adopt a style guide which documents how products should be written and usually includes specific guidance on how analysts should write common terms, date and time formats, and construct sentences to ensure a consistent voice within their intelligence products. Next, we'll explore the production process, which is where many of the concepts we have discussed come together into a unified production framework. Before we begin, it's important to note that there's no industry standard for this process, and each organization will follow a slightly different approach. The most important takeaway from this section is that intelligence teams should have some formal or documented production process to ensure the consistency and quality of its intelligence products. The sample process we'll be looking at includes six distinct steps prior to publication, most of which may be conducted by a team collectively, while others are performed by the lead analyst or author of the product. We'll look at each step individually, starting with the concept phase. The process begins when a team is either tasked with production or self-initiates production due to an incident, event, or development that falls within the team's intelligence requirements. Once a lead analyst or author is assigned to that task, the analyst will need to develop a concept for the product based on the incident, event, or development in question. This may entail choosing an appropriate product line, determining an appropriate timeline for publication, and developing a working concept for the overall product. Next, the analyst will need to conduct some initial research on the incident, event, or development to determine the key drivers and takeaways related to this issue, as well as develop some initial hypotheses. These hypotheses may eventually become the key judgments in the product if they're determined to be appropriately supported by available evidence. Once the analyst has developed the working judgments for the product, they should be reviewed by another member of the team to ensure that they are analytically sound and supported by sufficient evidence. Some teams approach this step in a group setting to allow several analysts to weigh in, question the lead author's logic or evidence, and propose alternative hypotheses. Once the team or the team lead is sufficiently satisfied with the strength of the lead analyst's judgments, the product begins to be drafted. The drafting process is usually performed by two members of the team, the lead author and a content editor or co-author, usually a senior analyst or intelligence manager. The goal at this point is to ensure that the judgments are clear and concise, flow together logically, and are supported by appropriate evidence in the bulleted sections of each paragraph. Once an initial draft is produced and approved by the editor or co- author, it is shared in draft format for peer review. Peer review will almost always include the rest of the intelligence team as well as any other members or teams in the organization that have subject matter expertise or equities in the topic. For example, if a CTI team was developing a product about a campaign targeting secure user authentication gateways, the author might ask the identity and access management team in their organization to review the product as well. Once the lead author has incorporated feedback and edits from the peer review process, a final draft will usually go to a senior analyst, manager, or designated editor for a final style and quality assurance review. This stage is different from the peer review in that the editor is not looking at the content or judgments of the product, but rather only looking at the language and style in which they are conveyed. For example, is the language at an appropriate level of complexity for the target audience? Does it adhere to the team's taxonomy and style guide? Is the spelling, grammar, and syntax all correct? Once the review is completed, the product should be ready for publication or dissemination to stakeholders. Before we conclude this module, let's take a moment to briefly review what we've learned. First, we discussed the importance of the production process and how this phase in the intelligence lifecycle is where all the previous work comes together. Production ensures that we are effectively communicating our analysis, judgments, and findings to our stakeholders in a way that they can understand and act upon. Next, we explored when to initiate the production process. To explore this concept, we used a model based on traditional intelligence tradecraft that has been modified to apply to the CTI field called the CAN model, which includes four general questions. Is this issue or event cyber threat related? Does analysis of this issue or event answer an intelligence requirement? Are there probable analytic findings or judgments related to the issue or event that will be actionable to stakeholders? And is this issue or event new, or is there a development related to it that is of probable current interest? From there, we discussed the types of intelligence products the CTI team might produce, including strategic, operational, and tactical products. The key takeaway here is that each product type generally has different target stakeholders, levels of technical sophistication, and common applications. Next, we discussed the intelligence product lines and why they're an important part of the overall communication process. Most importantly, intelligence product lines are developed to communicate a specific purpose and audience for the products associated with that product line. Then, we discussed some intelligence best practices related to product formatting and writing. These best practices help intelligence teams ensure the conciseness, consistency, and clarity of their products while also minimizing the time and effort required by stakeholders to understand and act upon that. Finally, we briefly explored the production process, which is used to ensure that our products are actionable, appropriate, and of high quality prior to dissemination to stakeholders. Thank you for completing the production module of the Cyber Threat Intelligence Lifecycle course. If you have any questions on this module, I can be contacted at Christopher.Carston at MasterCard.com. I hope you've enjoyed the module, and I look forward to seeing you during the wrap-up session.