the CYBER5

In episode 80 of The Cyber5, we are joined by Executive Director of the DISARM Foundation, Jon Brewer. 

We discuss the mission of the DISARM Framework, which is a common framework for combating disinformation. Much like how the MITRE ATT&CK framework is used for combating cyber attacks, the DISARM framework is used to identify what Jon calls “cognitive security.” What that means is all the tactics, techniques, and procedures used in crafting disinformation attacks and influencing someone's mind. This includes the narratives, accounts, outlets, and technical signatures used to influence a large population. We chat about what success looks like for the foundation and specific audiences used to help the population in understanding how disinformation actors work. 

Three Takeaways:

1. What is the DISARM Framework? 

DISARM is the open-source, master framework for fighting disinformation through the coordination of effective action.  It was created by cognitive security expert SJ Terp. It is used to help communicators, from whichever discipline or sector, to gain a clear, shared understanding of disinformation incidents and to immediately identify the countermeasure options that are available to them. It is similar to the MITRE ATT&CK framework which provides a list of TTPs that malicious actors conduct cyber attacks. 

2. Similarities Between DISARM and MITRE ATT&CK Frameworks: Cognitive Security vs Cyber Security

Cognitive security and the DISARM framework is analogous to cyber security and the MITRE ATT&CK framework. Cognitive security are the TTPs that actors influence minds and cyber security are actors’ ability to steal data from networks. MITRE ATT&CK’s list covers the different TTPs of the cyber kill chain: 

1. Reconnaissance
2. Resource Development
3. Initial Access 
4. Execution
5. Persistence 
6. Privilege Escalation 
7. Defense Evasion 
8. Credential Access 
9. Discovery 
10. Lateral Movement 
11. Collection 
12. Command and Control 
13. Exfiltration

DISARM’s list covers different TTPs of the disinformation chain: 

1. Plan Strategy 
2. Plan Objectives 
3. Target Audience Analysis 
4. Develop Narratives 
5. Develop Content 
6. Establish Social Assets 
7. Establish Legitimacy 
8. Microtarget 
9. Select Channels and Affordances 
10. Conduct Pump Priming 
11. Deliver Content 
12. Maximize Exposure 
13. Drive Online Harms 
14. Drive Offline Activity
15. Persist in Information Environment 
16. Assess Effectiveness

3. Disinformation: A Whole of Society Problem

While MITRE ATT&CK is mostly a business to business framework for enterprises to defend against cyber attacks. The DISARM framework is both a B2B framework for companies like technology and journalism, but also more broadly to consumers. This will take much more support from non-profits and public sector organizations like police and education systems.

In episode 79 of The Cyber5, we are joined by senior security practitioner, Garrett Gross. 

We discuss the age old problem of spear phishing and why enterprises still struggle to fix this problem. We talk about the critical processes and technologies necessary to defend against spear phishing, including robust training programs and endpoint detections. We also cover how to use the telemetry collected from spear phishing and integrate this with outside threat intelligence to be useful.

Five Takeaways:

1. Security Teams Need to Make a Sensor Network from the Employee Base 

Attackers win consistently when they get employees to click malicious spear phishing links. They use social engineered communications, usually over email, that appear legitimate but have malicious intent to trick a user to open a document or click on a link to obtain sensitive information about a user. 

Security training is boring and employees outside of security don’t pay attention to the annual reminders. Real education must be relatable to employees so that they can identify when a malicious link is deployed against them. The most critical training a security team can do is get a sensor network from their employees to spell out the ripple effects to employees for PII and intellectual property theft after a malicious link is executed. 

• Experts Must Create Critical Processes and Use Technologies Defend Against Spear Phishing

A closed door approach to security is not efficient. Experts transparently interacting with the employee base defends against spear phishing. A phased approach will be necessary to assess the necessary logging in an automated way as this takes months to configure and properly alert. The building blocks of this approach are: 

1. An endpoint detection and response solution (EDR) is the most important tool to defend against spear phishing.
2. An automated way to report incidents should be considered so users are not waffling on whether or not to report incidents. It should go without saying, but no one should get in trouble for reporting an incident. 

• Spear Phishing Typically Impersonates Executives; Executives Should Conduct PII Removal and PII Poisoning

The sophistication and reconnaissance of advanced adversaries are challenging to detect, particularly when bad actors impersonate executives. Verifying information over the phone is often needed to circumvent advanced attempts to social engineer an employee base. Further, publicly available information about executives should be scrubbed and removed from the internet on a routine basis. 

• Use of Spear Phishing Telemetry with Threat Intelligence for Small and Medium Size Business

Small companies with limited security personnel will be fortunate to get employees to get banners saying emails are coming from an external source. They will spend a small part of their day conducting internal threat hunting. They won’t be able to conduct external threat hunting to determine the sophistication of a spear phishing campaign.  They need to partner with managed intelligence providers to do external threat hunting effectively. 

• “Defensibility” Measures are Critical Success Metrics: Threat Intelligence and Red Teams

Quantifying reports and solutions that show how a security team is systematically reducing risks that affect their business is the only way budgets will get increased by the board. To prove that various attacks will matter to a business, threat intelligence with subsequent red teaming are the primary ways to illustrate the issues to an executive team.

In episode 78 of The Cyber5, we are joined by our guest, Gaurang Shah, former senior lead technology manager at Booz Allen Hamilton. 

We talk about the challenges of digital transformation and cybersecurity in the US federal government. We discuss solutions for bringing innovative technology and bespoke services into the federal space and how to shorten long procurement cycles. We also cover what the federal government can learn from the private sector, including how to shrink the ongoing cyber skills shortage. 

Four Takeaways:

1. Federal CISOs and CIOs Think Cloud Migrations Will Not Bake in Security

Outside of the US national security, intelligence, and DOD sectors, many civilian agency CIOs and CISOs in the US federal sector have the following shortcomings with regard to cloud migration:

First, they think security will be baked in as part of cloud migrations to AWS, Azure, or GCP when that is not reality. Second, cloud implementation is for infrastructure-as-a-service but way behind in software-as-a-service and application security. Third, they are either not aware of their expanding attack surface with a lack of enterprise security culture or there is an inability to gain funding for their security initiatives. Last, they have trouble retaining talent from the private sector.

• 2) Build Versus Buy Debate in the US Civilian Agencies

Procurement in many of the civil agencies within the US federal government is based on the lowest cost acceptable and not necessarily on value delivered for efficiency. They also cannot hire and retain talent at costs compared to the private sector, so building technology is extremely challenging. In many civilian organizations, they aren’t doing threat intelligence and incident response at the scale and speed necessary. 

• 3) Approaches for Overcoming Cyber Skills Shortage Gap

Understanding the federal government will lose on hiring top talent due to lowest cost acceptable restrictions in the procurement cycle, we recommend training IT, enterprise architects, database administrators, and system administration personnel who want to grow into security, particularly in automation. 

• 4) Future of Outsourcing to Managed Services Experts and Codifying Appropriate Threat Models

Some civilian agencies will likely need to outsource portions of SOC operations to managed services companies over the coming years. Some agencies are out-sourcing Level 1 alerting, for example, while keeping the escalations Level 2-4 in house. 

However, for the US federal government as a whole to be successful, there needs to be an agreed upon risk posture framework that many civilian agencies adhere to so that automation in detection and response can be achieved at the scale needed in the federal space. 

Further, application and software security are way behind and much of the focus is on infrastructure security. Unfortunately, outsourcing is still reticent in the federal space because of supply chain concerns. However, the federal government may have no choice but to implement aspects of next-generation SOC through outsourcing to a higher degree of experts. 

In episode 77 of The Cyber5, we are joined by our guest, Eric Lekus, Senior Manager for Threat Intelligence at Deloitte. Eric delivers for Deloitte’s internal security team and is not a client-facing consultant. 

We talk about how to evolve cyber threat intelligence in a SOC environment, beyond basic indicators of compromise (IOC) integration. We discuss the different stakeholders a CTI team has beyond a SOC, but also focus on what a CTI team needs to push and pull from a SOC to be relevant for a broader audience. We also outline success metrics for a CTI team.

Four Takeaways:

1. Indicators of Compromise are a Baseline Activity, Not Holistic Threat Intelligence

Indicators of compromise consist of known malicious IPs and domains. Stakeholders expect security teams to be doing this as a baseline. However, IPs and domains can change in the matter of seconds so it’s not fruitful to only rely on IOCs to be integrated into a SIEM that alerts with other network traffic and logging. 

2. A Security Operations Team Already Has A Rich Source of Baseline Activity; Enrich with Threat Intelligence

Security teams should be integrating many sources of logging, such as IPs from emails, using threat intelligence to alert on malicious activity. This should then establish two-way communication where a threat intelligence team is pulling information from the SOC to enrich and provide feedback. A SOC team is generally writing tickets for alerts and a threat intelligence team can’t just ask for bulk data; therefore automation to integrate into threat intelligence platforms is critical. A SOC analyst will ask, “what’s in it for me” and a threat intelligence professional should address this.

3. Threat Intelligence Should be a Separate Entity from the SOC; They Have Numerous Customers

The following services are generally associated with cyber threat intelligence teams. Since the SOC is a major stakeholder, the CTI usually has the following functions:

• Adversary infrastructure analysis
• Attribution analysis
• Dark Web tracking
• Internal threat hunting
• Threat research for identification and correlation of malicious actors and external datasets
• Intelligence report production
• Intelligence sharing (external to the organization)
• Tracking threat actors’ intentions and capabilities
• Malware analysis and reverse engineering
• Vulnerability Research and indicator of compromise analysis (enrichment, pivoting, and correlating to historical reporting)

4) Success for Security Teams Means Reducing Risk Through Outcomes

Regardless of who the stakeholders are in an organization, improving security should be focused around reducing risk and influencing outcomes for disrupting actors. This should be accomplished in alignment with the executive team and the culture of the organization. Showing how you are reducing risk over time is what makes threat intelligence teams successful in the eyes of business executives. 

In episode 76 of The Cyber5, guest moderator and Nisos Director for Product Marketing, Stephen Helm, is joined by our guest, Dr. Maria Robson, the Program Coordinator for the Intelligence Project of the Belfer Center at Harvard University's Kennedy School. 

We discuss the evolution of intelligence roles in enterprise and the ultimate path for intelligence professionals. We cover ethics in private sector intelligence teams and the role of academia in fostering not only the ethics, but also the professionalization of private sector intelligence positions. Dr. Robson also discusses insights into how proactive intelligence gathering capabilities tends to provide most value to enterprise. Finally, she gives an overview of the Association of International Risk Intelligence Professionals work and mission.

Three Takeaways:

1. Ethical Focus is Critical

Ethical lines of consideration and having a standard of what is appropriate for collection and analysis is important but currently very murky. Collection and analysis for the U.S. Intelligence Community would be entirely inappropriate and illegal when collecting against private sector persons and organizations. Standards would ensure, for example, that new analysts know what was in and out of bounds of the type of inquiry that can be answered. The Association of International Risk Intelligence Professionals (AIRIP) is leading the way to identify these standards.

• Apprentice and Guild Process is Critical if Standards are Slow to be Developed

Craft and guild process is important to get jobs in private sector intelligence because there is no linear pathway to employment. Since networking and a manager’s previous experience in the intelligence community, non-profit, or private sector are the driving forces behind mentorship, craft and guild benchmarking and professionalization become important models. 

• Security Organization and Reporting Structure Has Changed

Cyber threat intelligence, geopolitical risk, and corporate security have historically been the security functions. Before digging into how cyber threat intelligence benefits a physical security program, we identify a list of some of the services, products, and analyses that a CTI program might address. 

The following services have significant overlap with physical security programs:

• Adversary infrastructure analysis
• Attribution analysis
• Dark Web tracking
• Internal threat hunting 
• Threat research for identification and correlation of malicious actors and external datasets
• Intelligence report production 
• Intelligence sharing (external to the organization)
• Tracking threat actors’ intentions and capabilities

Other CTI services generally do not overlap with physical security and remain the responsibility of cybersecurity teams. These services include malware analysis and reverse engineering, vulnerabilities research, and indicator analysis (enrichment, pivoting, and correlating to historical reporting).

Security teams are now leveraging open-source intelligence and cyber threat intelligence to provide critical information to physical security practitioners. The physical and corporate security programs of these teams generally consist of the following disciplines, with use cases that are at the center of the convergence of cyber and physical security disciplines:

• Executive Protection and Physical Asset Protection
• Travel Security
• Regulatory/Environmental Risk Specific to Business
• Geo-Political Risk
• Supply Chain Risk Management
• Global Investigations

In episode 75 of The Cyber5, we are joined by Grist Mill Exchange CEO, Kristin Wood.

We discuss open source intelligence (OSINT) use in the U.S. public sector, not only with national security but also with the emergency response sectors. We talk about how open source intelligence has evolved in the last ten years and talk about how adversaries use open source intelligence against us. We also discuss how the U.S. needs to catch up with not only how to operationalize OSINT in meaningful ways, but how the U.S. government can procure bleeding edge technologies in a more time sensitive manner to meet mission requirements.

Three Takeaways:

1. Open Source Intelligence Has Evolved From Just Foreign Media; It’s The New All-Source Intelligence

The national security sector traditionally used open source intelligence as translating foreign media particularly during crisis situations. Now, open source intelligence is being leveraged in many ways like all source intelligence - the integration of human, signal, and imagery intelligence. Interconnectivity of devices has led to a commercial “goldrush” to aggregate data and sell it to public and private sector clients. 

• China is Remarkable at Open Source Intelligence Using Autocracy as an Advantage

China and Russia are collecting open source intelligence at an unprecedented level against the U.S. including what’s commercially available and through computer network exploitation and data exfiltration. 

They are aiming to reframe the U.S. using disinformation as a powerful tool. They have been very successful in leveraging online disinhibition effects against the U.S. populace.

• The United States Public Sector Needs an Overhaul in Procurement Authority

The U.S. private sector has a lot to teach the U.S. public sector in terms of learning consumer behaviors and how to pair that with commercially derived data, such as device fingerprinting, to extract valuable insights for national security purposes. To accomplish this, analysts need to be able to circumvent cumbersome government procurement buying cycles. 

In episode 74 of The Cyber5, we are joined by Robert Gummer, the Director of the Global Security Operations Center (GSOC) for the National Football League (NFL). 

First, we talk about how to expand the mission of a global security operations center (GSOC) using open source intelligence. We talk about the role of vendors in the GSOC ecosystem and how open source intelligence can be aggregated in the case management systems across all facets of a GSOC fusion center. We also talk about how to educate business stakeholders to make them a valuable intelligence consumer. We further discuss how a GSOC can model collection and analysis around successful outcomes for the business, both from a risk management function, but also as a business enabler.

Five Takeaways:

• Functions of the Modern Day GSOC: A Blend of Physical and Cyber Security

A GSOC is a fusion center - the blend of physical security, cyber security, emergency preparedness, business continuity, and global investigations around any and all threats to an enterprise.

Most physical security threats have a cyber or digital nexus. Active shooters, someone flying a drone over a location, and ransomware threats that shut down business continuity all have equal threats to business that need to be dealt with in a collaborative environment. 

• Key for Open Source Intelligence to Solve Business Problems: Eliminating Coverage Gaps is an 18-Month Process

There are two main categories of datasets to map, those are traditional open-source intelligence and non-traditional open-source intelligence. Traditional open-source intelligence datasets encompass the qualitative and quantitative collection and analysis of public, non-classified sources that deliver context such as archives, business records, dating sites and dark web. 

Non-traditional open-source intelligence datasets include the human, signals, and imagery intelligence equivalents in OSINT – based on anything from threat actor engagement on social media to external telemetry (netflow, passive DNS, cookies) to social media photos used to pinpoint locations.

Dialing in the threat intelligence landscape and reviewing vendors to determine who has the better social media and data coverage is a lengthy process, sometimes taking 18 months to get right. 

• Aggregation of Intelligence is Still a Maturing Process for Many Physical Security Teams

While mature physical security teams have an incident system that sends notifications for action, there still is not a single source of truth that aggregates everything together. 

Finding vendors that want to integrate with other vendor platforms is still a challenge.  Vendors should not look to displace other vendors, rather they should try to integrate with systems like a Virtual Contact Center (VCC) platform.

• Vendor Relationships are Partnerships and Real Intelligence Providers; GSOC Focuses on Educating Stakeholders to Drive Feedback and Integration with Business Requirements

There is no turnkey solution for triaging alerts in a GSOC and business stakeholders do not understand the GSOC and open source intelligence space. It takes months of triaging alerts and molding filters to get the right information that boils down real threats. 

Vendor relationships should be leveraged as partnerships to help triage the right alerts, give actionable intelligence, and integrate with existing enterprise systems. 

Then, GSOC stakeholders can spend more of their time educating the business stakeholders to become more valuable intelligence consumers where feedback is given that gives enterprises a competitive advantage with regard to risk. 

• Top 10 Use Cases for OSINT; Review of Tangible Examples

In addition to reputation use cases such as diligence on social media personalities that could negatively impact brands, below are 10 additional examples of OSINT use cases for the GSOC:

1. Executive Protection
2. Physical Asset Protection
3. Travel Security
4. Regulatory/Environmental Risk Specific to Business 
5. Geo-Political Risk
6. Global Investigations
7. Fraud Detection
8. Threat Surface Assessment
9. M&A Security Due Diligence
10. Ethical Hacking

In episode 73 of The Cyber5, we are joined by Snap Finance Chief Security Officer Upendra Mardikar.

We discuss how threat intelligence is used in application programming interface (API) security and development security operations (devsecops). Any organization building an application has data or user-generated content as the primary product.  Once connected to customers, consumers, clients, or partners there is a new set of security considerations generated.

The API serves as the software intermediary that allows two applications to talk to one another. It's bad enough if an attacker exfiltrates sensitive data, but imagine if they are able to gain visibility to see who is querying for the data held in the application. Imagine if Russia can see who is querying certain individuals in a credit bureau data set. That's a whole other set of problems organizations face. 

As we've talked about in previous podcasts, devsecops is the security of protecting the software development lifecycle (SDLC). We talk about why API security should be added to the wider MITRE ATT&CK framework and further discuss the impact of organizational immaturity as it relates to tackling API and DevOps security. 

Five Key Takeaways:

1) APIs are at the Forefront of Digital Transformation and Must be Protected

APIs go north/south between the company and customers and east/west establishing interconnectivity between different applications within the enterprise.  A giant need exists to go “outside the firewall” to observe threats that are attacking APIs because they are fundamental to many enterprise functions, regardless of industry. 

2) API Security is Very Immature in Enterprise

Many security practitioners focus on north/south protections of APIs and implement firewalls and DDoS protections to keep intruders out of the environment. However this is a myopic strategy because it does not protect against lateral movement and privilege escalation when an attacker compromises perimeter security. When perimeter security is compromised, protecting east/west APIs becomes critical. We are seeing trends around Zero Trust.

Zero Trust is based on the premise that location isn’t relevant and users and devices can’t be trusted until they are authenticated and authorized. To gain security from a zero trust security model, we must therefore apply these principles to our APIs. This aligns well since modern API-driven software and apps aren’t contained in a fixed network — they’re in the cloud — and threats exist throughout the application and infrastructure stack.

An API-driven application can have thousands of microservices, making it difficult for security and engineering teams to track all development and their security impact. Adopting zero trust principles ensures that each microservice communicates with the least privilege, preventing the use of open ports and enabling authentication and authorization across each API. The end goal is to make sure that one insecure API doesn’t become the weakest link, compromising the entire application and data.

3) Integrating API Security into the MITRE ATT&CK Framework

API Security is different from traditional application security (OWASP), which is integrated into the MITRE ATT&CK Framework along with attacks on servers, endpoints, and TLS, etc. API security focuses more on the potential attacks of exposed, internet-facing microservices in addition to the business logic. API security primarily focuses on:

• Users: The most common API vulnerabilities tend to be centered around issues with an authorization that enables access to resources within an API-driven application.
• Transactions: Ensuring that transport layer security (TLS) encryption is enforced for all transactions between the client and application ensures an extra layer of safety. Since modern applications are built on microservices, software developers should enforce encryption between all microservices.
• Data: It is increasingly important to ensure sensitive data is protected both at rest and while in motion and that the data can be traced from end-to-end.
• Monitoring: This means collecting telemetry or meta-data that gives you a panoramic view of an application, how it behaves and how its business logic is structured.

4) Improvements for Threat Intelligence Against APIs of Applications 

Threat intelligence providers need to go beyond the features of user stories, but also be able to alert and automate when malicious actors are targeting the microservices of APIs as the business logic of these APIs are more central to business operations. 

5) Threat Intelligence Should Try to Integrate with Threat Hunting to Conduct Proper Malicious Pattern Matching, Reducing False Positives

Pattern matching to detect malicious behavior over legitimate user traffic has evolved over time:

• Netflow: track network traffic emanating from the routers to the endpoints
• Applications: track application traffic to deter anomalies of authentication
• Data: track data flows in motion and at rest in the data lakes
• Devices: mapping devices to determine proper asset inventory
• Users: tracking user behavior such as off business hour queries to sensitive databases

The industry still needs solutions that detect and correlate these behaviors at scale because thus far this has been extremely fragmented.

In episode 72 of The Cyber5, we are joined by DoorDash Application Security Manager, Patrick Mathieu.

We talk about threat intelligence's role within applications security programs, particularly programs focusing on fraud. We discuss the importance of prioritization between what could happen, as often seen in penetration testing, and what is happening, as often seen with threat intelligence. 

We also talk about the different types of internal and external telemetry that can be used to drive a program and discuss the outcomes that are critical for an application security program to be successful. 

Three Key Takeaways:

1) Application Security Overlaps and Threat Intelligence Shortcomings

Fraud programs exist to save money and application security programs exist to discover and mitigate cyber vulnerabilities. However, most of the same problems are derived from the same weaknesses in the application architecture during the software development lifecycle (SDLC). 

Any application development team needs to know the following:

1. Attacks: Understand the threat, who is attacking, and what they are attacking. The threat could be the server, the client, the user, etc. 
2. Custom Angles: A fraudster is always going to attack the business logic of an application, the custom rules or algorithms that handle the exchange of information between a database and user interface.
3. Obscurity: The threat will not likely be in the news, such as a ransomware group. As a technology company grows, an application will gain interest from fraudsters who will try to abuse the application. 

Threat intelligence falls short in collecting against these actors because it’s so specific to business logic and not an organized crime group with greater notoriety or known tactics, techniques and procedures (TTPs). 

2) Common Vulnerabilities in Application Security Pertinent to Fraud

1. While injection attacks are still common, the most common application vulnerabilities are fraudulent authentication attempts and session hijacking. Microservices (token sessions, for example) are common in applications. However, it’s very challenging to know who is doing what in the application - for example, knowing whether it’s a consumer, an application developer, or fraudsters. 
2. Many companies do not have an active inventory of asset management, particularly with their applications. 
3. There is little visibility for analyzing the logs on the Web Application Firewall (WAF). Every application is different and understanding what is normal versus fraudulent takes time and modeling to focus on who is attacking business logic for fraudulent gains. 

3) Application and Security Engineers Must Communicate

1. Security champion programs are critical to getting application and security engineers to communicate in a way that articulates what is normal in an application. If this collaboration does not work, the attackers will be able to collaborate quicker to execute. 
2. Adoption rates of application engineers are a better metric to monitor versus showing remediation of vulnerabilities. 

In episode 71 of The Cyber5, guest Nisos moderator and teammate Matt Brown is joined by security practitioner Matt Nelson.

They talk about a recent intelligence blog Matt Nelson wrote about how to operationalize intelligence for the SOC and some outcomes that an incident response team looks for from intelligence. They also talk about how to make intelligence more broadly used for investigations and discuss the intelligence market more holistically.

Three Key Takeaways:

1) Threat Intelligence Augments Threat Hunting in the Security Operations Center (SOC)

Intelligence requirements are critical throughout the business and not just limited to the SOC. Threat intelligence can be a significant help to the threat hunting and detection team. The outcomes that threat hunting teams generally look for are:

1. Cyber Kill Chain: Analyzing payload, including commands it’s running, attack hosting infrastructure, what ports is the infrastructure using to communicate, etc.
2. Target Verification: Identifying who and how they are being targeted and for what intent is often missing context when just looking solely at forensics data. 
3. Collection Intent of Attacker: Trying to determine what kinds of data the attackers are aiming for. This is hard to determine simply from forensics data. 
4. Target of Opportunity Versus Targeted Attack: Determining if attacks are targeting the many or the select few is critical for defense strategies. If targeting efforts are directed solely at IT personnel with admin access, that’s more significant than a “spray and pray” campaign. 
5. Outcomes: Outlining detections, protection strategies, and awareness campaigns.

2) Evolving Threat Intelligence Beyond the SOC

Threat intelligence is not just cyber news or indicators of a compromise (IoC) feed. Threat intelligence is useful for insider threat, fraud, platform abuse, corporate intelligence, and supply chain risk. 

3) Single Data Aggregators for Enterprises (SIEMs, TIPs, MISP) Aren’t the Panacea 

1. The SIEM is not the greatest place for threat intelligence data because there are too many internal logs that aren’t relevant.
2. The TIPs are mostly focused externally and good for IOCs and correlating threat intelligence that’s not useful. It’s simply repeating what is already known. 
3. MISP (https://www.misp-project.org/) is open source but can be effective with the right resources. Data modeling and getting the right taxonomy of the data is the most critical.