5 September 2023, I spoke on the cyber security summit in Singapore. About "Cyber Threat Intelligence Use Cases"

• CTI USE CASE 0: Keyword Repository
• CTI USE CASE 1: Intelligence Platform Alerts
• CTI USE CASE 2: Cyber Threat Intelligence Feeds
• CTI USE CASE 3: Vulnerability Intelligence
• CTI USE CASE 4: Infostealer monitoring
• CTI USE CASE 5: Daily CTI Report
• CTI USE CASE 6: Phishing Intelligence
• CTI USE CASE 7: Threat Hunting
• CTI USE CASE 8: Internal Strategic Intelligence Report
• CTI USE CASE 9: External Strategic Intelligence Report
• CTI USE CASE 10: Threat Intelligence Sharing

Hereby the slides that were shared:

• CyberThreatIntelligence(CTI)UseCasesv1.0.pdf

Recently I had the opportunity to present to a group of Cyber Security Professionals on the topic of SIEM and SOC. It's a summary of most of my previous blog posts.

DesigningTheSIEMMonitoringEnvironmentToAddressVisibilityandBlindSpots_v1.0.pdf

I have studied the SANS GCTI and EC-Council CTIA Cyber Threat Intelligence (CTI) certificates quite extensively and have attempted to summarize the 20% of the knowledge that would provide 80% of the domain knowledge coverage. Hopefully it's of value to someone not familiar on the topic or someone that is a seasoned professional on the topic.

CTI FOUNDATIONS

• Cyber Threat Intelligence (CTI) is the collection and analysis of information about cyber threats and adversaries. Driving the creation of threat models that provide an ability to make knowledgeable decisions for cyber threat preparedness, prevention, detection and response actions against various existing, emerging, predicted cyber threats or attacks
• The Cyber Threat Intelligence (CTI) program helps Senior Business leaders make informed forward-leaning strategic, operational, and tactical decisions on existing, emerging, predicted cyber threats or attacks to the organization
• Cyber Threat Intelligence (CTI) helps the organization's to identify and mitigate various business risks by converting unknown threats into known threats and helps recommending various advanced and proactive defense strategies
• Cyber Threat Intelligence is both a product (report, presentation or message) and a process (collect, process and produce)
• The organization develops their Cyber Threat Intelligence (CTI) Strategy based on their business requirements and risk level

CTI BUSINESS VALUE

• CTI Helps reduce the effectiveness of existing, emerging, predicted cyber threats or attacks faster and better
• CTI Helps in recommending actionable strategies and tactics that can be implemented to help mitigate cyber risk
• CTI helps organizations identify adversarial opportunities for attack and proactively mitigate cyber risks
• CTI Provides high-level situational awareness to management and executives to understand significant threats to protect critical assets and business processes
• CTI Provides analyzed Threat Actor Campaigns that help security teams shift their investigation from specific indicators to attack TTPs, speeding up their investigations

CTI REQUIREMENTS

• Cyber Threat Intelligence products should be: Objective, Timely. Accurate, Actionable
• Cyber Threat Intelligence requirements need to come top-down NOT bottom-up
• Cyber Threat Intelligence works best on top of a already functioning security program which sits on top of a mature IT organization
• Actionable Threat Feeds require Quality IOC's (low volume, high quality) over Quantity IOC's (high volume, low quality)
• General Requirements for CTI Success: A Solid Planning and Direction document, Priority Intelligence Requirements (PIR's) and a Mature, well-functioning IT organization

CRITICAL THINKING

• Working in Cyber Threat Intelligence is all about defeating cognitive biases to ensure an objective and accurate intelligence product
• Security personnel often use their experience as full bias to quickly come to conclusions during investigations
• All Threat Analysts have biases (those biases can be good, effective and quick, but they also can cloud judgement)
• Cognitive Biases or Fallacies: Correspondence Bias, Confirmation Bias, Self Serving Bias, Belief Bias, Hindsight Bias, Anecdotal Fallacy, Appeal to probability, etc.
• Counter-bias Strategies: Decision Theory, Game Theory, Behavioral Economics, Cognitive Psychology, Machine Learning, Human Reliability Engineering

CTI CONCEPTS

• Actionable Threat Intelligence = Objectively written + Timely delivery + Accurate facts + Actionable Recommendations
• Threat = Opportunity + Capability + Intent
• Attack = Motive (Goal) + Method + Vulnerability
• Threat Actor Campaign = Actor Name + Observed Attacks/Intrusions + Actor TTP's + Key indicators (IOC's or IoA's)
• Threat Assessment = Confidence levels + Analysis + Evidence + Source References

DISTINCTIONS

• Types of Threat intelligence: Strategic Threat Intelligence, Tactical Threat Intelligence, Operational Threat Intelligence, Technical Threat Intelligence
• Types of Intelligence Sources: Open-Source Intelligence (OSINT), Human Intelligence (HUMINT), Cyber Counterintelligence (CCI), Technical Intelligence (TECHINT), Social Media Intelligence (SOCMINT)
• Types of Cyber Threat Actors: Insider threat, industrial spies, Script Kiddies, Organized Hackers, State-Sponsored Hackers, Suicide Hackers, Cyber Terrorists, Hacktivists
• Types of Intelligence Tools: Link Analysis Tools, Threat Modeling Tools, Threat Feed Aggregators, Threat Intelligence Platforms
• Types of Attribution: Group Attribution, Campaign Attribution, Intrusion-set Attribution, True Attribution, Nation-state Attribution

RESOURCES

• Lifecycles: Cyber Threat Intelligence Lifecycle, Indicator Lifecycle, Advanced Persistent Threat Lifecycle, Ransomware Lifecycle, OODA Loop
• Attacker-Centric Threat Modeling: Kill Chain, ATT&CK, Diamond Model, VERIS, Security Cards, Persona Non Grata, Attack Trees, CAPEC, INTEL TARA/TAL, Invincea
• Data Analysis Methods: Analysis of Competing Hypotheses (ACH), Opportunity Analysis, Linchpin Analysis, Analogy Analysis, Cone of Plausibility, Timeline Analysis, Critical Path Analysis
• Technical Formats and Standards: STIX, TAXII, CybOX, OpenIOC, Snort, YARA, SIGMA, CACAO
• Other: Traffic Light Protocol (TLP), Pyramid of Pain, Threat Intelligence Maturity Model

UPDATE: Based on feedback I have adjusted the model to a v2.0 version.

Within Cyber Security Operation Centers everywhere in the world, everyday new "freshers" are on-boarded as L1 Analysts within monitoring teams. Some of these CSOC’s will have a proper on-boarding training and some will have not. Some will receive personal one on one coaching and some will have not. Some will be trained by very senior analysts and some will be trained by someone who are just as junior as them.

At this point in time, I have not come across a proper articulated model that encompasses all of the most important knowledge topics a Cyber Security Analyst might need to understand, know or to lookup in the individual’s career development path. Therefor based on my previous experience and current understanding of the theoretic models I have attempted to simply, unify and provide a framework to built a career development path for Cyber Security Analysts all around the world.

The key message here is:

“A senior cyber security analyst should be able to reach the simplicity at the far side of complexity and to be able to communicate the cyber security risks, threats and related countermeasures simply, effectively and actionable.”

Key Critical points before reading the model:
1. Countermeasures can be highly detailed or highly general, due to the simplicity of the model this item does not entirely correspond with the “Detail vs. General” axis.
2. This for a cyber security analyst specifically and excludes other roles like: Threat Hunter, Cyber Threat Intelligence Analyst, Use Case Developers, Penetration testers, etc. Although a lot of this required understanding overlaps of some of these roles.
3. Not every item will weigh as heavily for the business as other items. For example, understanding who the threat actor is might not always be as important as what the preventive countermeasures are for the organization. Knowing what to study more or less in-depth is a piece of wisdom a analyst will learn over time within the organizational context it is active and accumulated experience the individual gains over time.

How to use this model? There are several ways to utilize this model:
1. Feedback - A framework for providing analysts feedback where their analysis has potentially missed a point or falls short.
2. Interview - The red questions can be asked and answers scored against a Junior, Medior or Senior Analyst scorecard.
3. Career Planning - Map IT/Security Certificates against every red question and put time/dates against them.
4. Analyst Automation - Map look-up's to supported or existing automations/enrichments.

Anybody that has been working in (or with) the Cyber Threat Intelligence (CTI) industry has probably come to the conclusion that not all CTI vendors cover the same intelligence sources and sometimes if they cover a source, there are vendors that take a more "quantitative" approach and some vendors that more of a "qualitative" approach.

For example scraping TOR pages and indexing them is a example of a "quantitative" darknet intelligence approach. While actively being on TOR forums and related chat groups is considered a "qualitative" darknet intelligence approach.

The wide variety of different intelligence sources that are out there is also quite challenging for some to get a handle on when they are just entering in the CTI domain. To help those who are just starting up their CTI program I've created a overview diagram with some key pointers to help them navigate this domain of cyber security.

Critical Note: This diagram is a reflection of the Cyber Threat Intelligence commercial offerings out there and might have not covered all intelligence sources possible in the world.

KEY POINTERS WHEN STARTING YOUR CTI PROGRAM:
1. Start with a "planning and direction document" to derive the Priority Intelligence Requirements (PIR)
2. If you have limited or non-existent budget start with open source/free first.
3. Be aware that a vendor collection scope might overlap but might vary in terms of quantity or quality.
4. There is no one single vendor that does everything perfectly making distinctions between types of vendors helps combining the ideal package based on your PIR's:
   - Quantitative Intelligence Vendor
   - Qualitative Intelligence Vendor
   - Aggregation & Enrichment Platform Vendor
   - Analysis & Production Platform Vendor
   - Dissemination and Integration Platform Vendor
5. SOAR seems one of the best solutions out there that is able to consolidate, automate and distribute intelligence according to standardized workflows to it's stakeholders (although only a sub-set of SOAR vendors support TIP-like platform capabilities).

Currently there are many cyber security vendors out there that provide solutions that offer "AI" (artificial intelligence) or "ML" (machine learning) without specifying what that actually entails within their point solution. This has created some aversion among cyber security professionals against vendors that blatantly use this type of "marketing lingo".

Some of these vendors actually provide some shape of form of a "narrow AI" that is generally (for example) following a limited logic:

• Detect IP -> Classify as a threat -> block IP on firewall
• Detect endpoint -> Classify as a threat -> isolate endpoint
• Detect User -> Classify as a threat -> disable user on IAM solution

Generally all AI that only pertains to cyber security risk is a narrow A.I., but in these cases it's even more narrow as of the limited closed OODA (observe, orient, decide and ACT) loop provided by the solution. Besides that most vendors are just using their "point solution" as the AI and doesn't take into account the wider landscape of "AI" opportunities within the cyber security solution stack of the organization.

This made me put together an architectural diagram trying to fit in a series of solutions and concepts that would be able to provide a more wider foundation for the fully automated "OODA" loop that AI is trying to achieve within the cyber security space.

The following diagram highlights the gaps currently within this potential future target architecture following the general definition of what "AI" supposed to do.

Artificial intelligence (AI) refers to the simulation of human intelligence in machines that are programmed to think like humans and mimic their actions.

Currently there are the following gaps in the CSOC context regarding the implementation of this form of AI, as there is no out-of-the-box solution that can do all of the following:

• NO FULLY AUTOMATIC LOG SOURCE ONBOARDING
• NO FULLY AUTOMATIC THREAT DETECTION RULE CREATION
• NO FULLY AUTOMATIC PLAYBOOK CREATION
• NO FULLY AUTOMATIC RESPONSE SELECTION
• NO FULLY AUTOMATIC AUTOMATION INTEGRATION
• NO FULLY AUTOMATIC RESPONSE SELECT / EXECUTE

Because of these technologies will take a while to develop the move to this targeted architecture is accelerated by the move to the cloud as this will provide more standardized closed loop environments and with the drive for API-centric design in all application/systems nowadays (allowing for either extraction of events and actions on the application/system) we are getting more close to this type of environment.

Conclusion:
Use this diagram as a target reference architecture, setup your CSOC architecture to allow and measure on increased micro implementations of closed "OODA" loops to accelerate getting to this targeted AI vision within the CSOC in the long term. With this in mind we might be able to use a series of "fully automated OODA loops" stacked upon each other, to make it look like as something that closely resembles the "Cyber Security AI" architecture.

TLDR: Here is a summary

As the world is rapidly adopting cloud platforms among the world, organization’s dependency on additional SaaS, PaaS and IaaS vendors increases. The need for cyber security in these cloud-native contexts also arises because of this. When we look at for example isc2’s CCSP (Cloud Certified Security Professional) certificate they put forward IRM, DLP and SIEM as key tools to track, control and monitor data in the cloud. In this Article I want to zoom in and highlight a series of challenges regarding the monitoring of these solutions using the SIEM as a method for securing the cloud.

SIEM’s can ingest logs from many different sources for threat detection and in the cloud context these sources will primarily come in API log integrations (streaming or bulk). The problem comes in if one’s organization already has many cloud native applications, has over a 100/1000+ cloud-native SaaS services each with their own API’s and your goal is to onboard these log sources into your SIEM tool of choice. The following challenges try to outline the major issues with all these API integrations and propose potential solutions for API developers of these cloud services to provide an increased level of satisfaction with their customers and an overall increased security posture in the cloud landscape.

Critical Note 1: This is the current status as I have experienced it in the cloud landscape, this might or might not rapidly mature overtime and in the future these challenges might be less of an issue.

Critical Note 2: The cloud landscape is a wide landscape with many different vendors ranging from high and low maturity therefore these challenges might or might not apply for some of them depending on situation.

Critical Note 3: Some of these items are not new challenges but general challenges with any shape or form of log collection.

1. API Log Collection Endpoints are Sometimes Not Available
Most cloud native apps that are created generally are built from the “API-centric” philosophy unfortunately these API endpoints are generally focused on application functionality and generally do not provide an audit/security logs retrieval API endpoint.
Recommendation: Create an API endpoint for audit/security logs within your cloud service.

2. API Log Collection is Barely Real-Time and Sometimes Even Very Delayed
Some cloud vendors provider an API endpoint for log collection but when configuring this on your SIEM of choice, one might be hesitant to pull every 30 seconds logs from this endpoint and moves it to 5 minutes in order to reduce overloading/trigger rate limiting on the API. Besides that, once the log is pulled in some vendors might have a back-end delay ranging from a couple of minutes to one or many hours when it comes to piping these events into the API endpoint this is very troubling if one wants to do real-time or near real-time threat detection with a SIEM.
Recommendation: Create an audit/log API endpoint that provides logs in (near) real-time.

3. API Log Collection Availability is Rarely Committed in Cloud-Centric Vendor Contracts
Generally, a cloud service comes with an SLA that agrees on the availability of the service provided in terms of percentages, unfortunately it is all too common this is not scoped in for API endpoints that provide audit/log capabilities although this might be critical for some customers due to reporting or compliance requirements. This allows cloud vendors to have long term outage or extreme log delivery delay on an audit/log endpoint and not be accountable or penalized in terms of the contractual context of the cloud service.
Recommendation: Commit to API audit/log endpoint availability metrics inside the SLA.

4. API Log Collection Audit/Log Data is Sometimes Limited or Unusable for Threat Detection
In cases where the API endpoint is in place for audit/log collection and events are coming in, sometimes the API is not developed and key fields used for threat detection might be missing, for example: Source IP, Account name, UserAgent, Endpoint called and Action executed. This renders the onboarding initiative for the Audit/Logs through the API as a non-productive activity.
Recommendation: When creating an audit/log Endpoint provide as much useful data as possible.

5. API Log Collection Sometimes is an Additional Paid Service
There are cloud vendors out there that require the customer to pay additional money and subscribe to an additional subscription in order to provide their API audit/log endpoint access to the customer. This is very annoying if you are trying to onboard many different cloud apps. Many of these initiatives stop because of a commercial challenge involved causing a blind-spot in security monitoring the specific cloud service in terms of security monitoring. In my opinion If it’s your own data you should be able to access it without additional cost, this is just like charging for an additional napkin inside a restaurant.
Recommendation: Provide audit/log API endpoint as part of the standard package.

6. API Log Collection Endpoints for “Transparency Logs” are very uncommon among vendors
Transparency logs pertain to the backend operators that access your data, transparency logs might provide critical insight into the behavior of the cloud vendor as these might look into your sensitive data for no real-reason beyond the administration of the cloud service. This is still a relatively new thing for most cloud vendors and therefore is mostly absent from most API endpoint offerings.
Recommendation: Provide a “Transparency Logs” API endpoint as part of the standard package.

7. API Log Collection Tokens Do Not have a Dedicated “Audit Log Viewer” role
When onboarding an API log sources inside the data collection tool like a SIEM you are generally required to use an API token for authentication, along with this API token there is also an authentication role associated that provides the access to the specific endpoint required. Unfortunately, it is all too common that a token needs a “full admin” authorization role to just access the basic audit/log API endpoint, creating an additional risk when accidentally leaking the key.
Recommendation: Provide a dedicated “Audit Log Viewer” authentication role for log collection.

8. API Log Collection Delivery Methods Vary and Might Have Rate Limiting or Hard Limits in Place.
There are a variety of API log collection methods in place each with their pro’s and con’s, generally the decision is made based on what the cloud vendors application context is. Collection mechanism might be for example a: “streaming API” (streaming events in near real-time), there is a “streaming API” with a backlog function (halts every half hour and then clears the backlog in order to continue streaming again), “Bulk (or batch) API” every period a batch of logs are pulled or pushed using a established or scheduled a API call. On top of that rate limiting might be in place to limit events per API call or overall hard limits on how many events can be pushed out over a period of time.
Recommendation: Provide dashboarding and configuration options on API usage and limits.

9. API Log Collection Methods are Constantly Changed and are Not Standardized
Although most API log collection endpoints are using a restful JSON based API and most of them are speaking the same protocol, every interaction still varies vendor per vendor depending on authentication schema’s, delivery method’s, API rate limiting and other challenges mentioned before requires every Security Monitoring vendor to create their own Integration code for every cloud vendor causing a lot of work of tracking and integrating every new cloud vendor’s API’s for log integration. Sometimes these API endpoints are modified without informing the end-user or completely deprecated without announcement causing the endless loop of trying to catch up with cloud vendors on their log collection services. There is no global standard (as far as I have seen) regarding a standardized API endpoint log collection pattern that is replicated across all vendors easily with the likes of let’s say “syslog”.
Recommendation: Comply to an API industry-standard and inform users timely when changed.

10. API Log Collection Audit Log Sometimes Has 1 Array with Highly Dynamic Bulk Data Population
In some cases, an API endpoint provides all the things we need as a Security Monitoring professional but due to the large amount of data an application produces many different “columns” of data is pushed into a key value pair series into 1 JSON array. On top of that these columns might vary per events causing even more additional challenges in terms of normalization of these logs when parsing the JSON events to a readable format. In traditional log collection, using a CEF (Common Event Format) was generally the solution for these dynamic fields: “devicecustomstring1, 2, 3” etc. Unfortunately, this is not used commonly within API endpoints from the start.
Recommendation: Split data using a standardized log format in separate arrays, not bulk populate.

In 2014 I'd written an article on the hard question of "Which SIEM use cases has most value/effect for the organization?" during my years in security I learned the answer to this question has been always "it depends".

Yes.. but what does it really depend on? well on:

• Business Context
  
• Business Content

Okay but how do I translate this to the use cases I want to built? Well you use:

• Your Threat model or models of choice
  
• Use case Management Process
  
• Use case Framework

To bring this all together I've created a diagram that proposes a 3-step approach that tries to answer the question "Which Prevention, Detection and Deception use cases have the most value/effect for the organization in terms of risk coverage?".

Proposed 3-step approach

1. Collect, Identify and Prioritize Risks, Attackers, Software and Assets.
2. Decide and Apply a “Threat Modeling Strategy” based on Attacker, Software, Asset or Risk-Centric Threat Models.
3. Identify, Prioritize and Operationalize: Use Cases and Integrations.

Following these steps will help make your Prevention, Detection and Deception use cases a success.

The following diagram comes with a few caveats:

1. Not all information might be available in the organization where you apply this approach to (all is best effort), it can also be the other way around some organizations might have even more information then currently described in the diagram (more information is always better).
2. The threat models divided in the four major categories are an oversimplification as some models are combinations of different functions causing overlap between categories in some cases. The goal of every category is to emphasize the model's inherent primary bias.
3. The definition of the Use Case Framework is stretched over Prevention, Detection and Deception Technologies.
4. The Technology list is limited and is probably missing lots of additional technologies that didn't fit on the diagram (there for the "...*")

The attacker-centric Threat model bias

One of the key reasons I've created this diagram is that there seems to be an industry level bias emerging where an "attacker-centric" model (in specific Mitre ATT&CK) is the end-all and be-all of all detection use cases. Which creates a Asset, Software and Risk-centric blindspot. To tackle this, I recommend deciding on a "threat Modeling Strategy" to avoid such blind spots. I propose choosing a combination of "centric's" that tries to cover the threat landscape as best as possible (know your yourself and know your enemy is definitely a key strategic start point).

Some key points on choosing a threat model:

• No single Threat Model Methodology covers all dimensions of importance to it's maximum level.
• The quality and scope of threat identification differs among classes of Threat Model Methodologies.
• Not every Threat Model Methodology is equally well suited for finding all types of threats.
• Threat Model Methodologies exhibited substantial trade-offs among reported threats, potential false positives, and frequency of reporting in terms of complexity, time to execute and ability to automate.

For merging any type of Threat modeling combination into a Use Case Framework I recommend using The SPEED SIEM Use Case Framework. This specific framework use Mitre ATT&CK as attacker-centric threat model and for asset, software or risk-centric there is a directory structure that can facilitate any of the chosen threat models.

Research references
If you want in-depth comparisons of the different threat modeling methodologies please look at the following resources:

• Mitre - Cyber Threat Modeling: Survey, Assessment, and Representative Framework
• Carnegie Mellon University - Threat Modeling: A Summary of available methods
• Selin Juuso - Evaluation of Threat Modeling Methodologies
• International Journal of Pure and Applied Mathemati - Profiling Threat Modeling Approaches and Methodologies for IT and Cloud Computing
• Carnegie Mellon University - Evaluation of Competing Threat Modeling Methodologies
• Practical DevSecOps Awesome Threat Modeling List on Github

Conclusion
1. Make sure you do enough contextual and content based data collection before you start threat modeling.
2. watch out for the attacker-centric bias when choosing a threat model.
3. Use a combination of threat models that fit the organization and your cyber security objectives the best.

Within the last few years there has been a mainstream trend of the idea of "Fake News" or in other terms "disinformation". Before we step into the topic it might be helpful to look at the definition of disinformation:

"Disinformation is false or misleading information that is spread deliberately to deceive. " - Wikipedia

This trend was even more underlined with the revelations of Cambridge Analytica where a private firm was used to create and run highly targeted and sophisticated disinformation campaigns on political voters through social media across different geographical regions. Now as we are experiencing the global Covid-19 crisis the acceleration of the 4th industrial revolution (communication and inter-connectivity), more and more people are active on the internet and social media. This in turn also increases the opportunity (financial or otherwise) of companies similar to Cambridge Analytica to actively run disinformation campaigns for their customers on this emerging new group of internet users.

How does disinformation relate to Cyber Threat Intelligence?

Most organizations that are currently setting up their Cyber Threat Intelligence (CTI) function are still in a relative immature stadium and are generally not facing challenges of disinformation contaminating of their intelligence sources (at least there is no widespread crisis as of yet in the community). But, there is a real risk that these disinformation campaigns will break out of the political domain and influence available Cyber Threat Intelligence sources from organizations in the future this is where the relation with Cyber Threat Intelligence Services comes up.

How does disinformation effect the quality to Cyber Threat Intelligence?

With these disinformation campaigns running (currently or in the future) in the wild there is a real risk of quality degradation of the major quality factors that a Cyber Threat intelligence product should posses. This is as an after affect of having bad or contaminated intelligence sources used to produce the intelligence products. The final intelligence product quality factors that are impacted by a disinformation campaigns are the following:

• Completeness - Expected comprehensiveness, intelligence can be complete even if optional data is missing. As long as the data meets the expectations of the consumer then the data is considered complete.
  * The new emerging requirement mind be that existing disinformation narratives should be mentioned when reporting on certain cyber threats.
• Objectiveness - The method of intelligence collection and analysis must ideally always come to the same intelligence product and should be politically neutral.
• Accurateness - The degree of the intelligence product resembling reality, disinformation might skew this towards falsehood.
• Contextualization - The context surrounding the intelligence product, it might be sometimes important to mention disinformation campaigns as context where a certain threat is related to.

It is also important to mention that a disinformation campaign can be a precursor to a cyber attack, this might help anticipate or even predict certain attacks to emerge on the cyber threat landscape.

The proposed solution: "Disinformation Analysis Service"

To be able to counter this quality degradation of the intelligence product it might help being aware of any active disinformation campaigns that are run throughout the global cyber threat landscape. I want to propose a solution to augment the existing Cyber Threat Intelligence (CTI) function with a supportive "Disinformation analysis Service" within a Cyber Threat Intelligence Center (CTIC). This will help augment the existing CTI Analysis processes with a "disinformation aware" dimension and helping push up the completeness, objectiveness, accurateness and contextualization of the final threat intelligence product.

To illustrate the relation between CTI Services, Quality factors and Disinformation analysis services I've created the following diagram:

How will the "Disinformation Analysis Service" work within the intelligence lifecycle?

To get more specific what a this service might entail we can look at the Cyber Threat Intelligence lifecycle.

• Planning and Direction - First things first: the requirement should be there from the organization or the emerging threat landscape to actively augment the intelligence product with possible disinformation campaigns.
• Collection - Source selection of organizations that actively track disinformation campaigns in the world, ideally across geographical regions to start actively collecting from.
• Processing and exploitation - Standardized methods of collections (like TAXII and STIX) should lead to automated collection and enrichment within the Threat Intelligence Platform of active or emerging disinformation campaigns.
• Analysis and production - Analyzing disinformation campaigns and seeing how they relate to the existing organization's threat landscape.
• Dissemination and integration - Communicating the relevant disinformation campaigns to the other Cyber Threat Intelligence Analysis functions within the Cyber Threat Intelligence Center (CTIC).

How can one model disinformation campaigns in a standardized format?

To be able to consume, produce and distribute Disinformation intelligence it needs to be normalized in a framework that is of similar nature like the MITRE ATT&CK framework. Introducing Credibility Coalition's AM!TT Framework:

AMITT (Adversarial Misinformation and Influence Tactics and Techniques) is a framework designed for describing and understanding disinformation incidents. AMITT is part of misinfosec - work on adapting information security (infosec) practices to help track and counter misinformation, and is designed as far as possible to fit existing infosec practices and tools. - AMITT Github Page

This framework has a similar structure as ATT&CK with phases, tactics, tasks and techniques in a single overview. In the following diagram you can see the these different phases in a detailed manner.

Additional information on every specific step can be found at: AMITT Github Page in their recent update they have stated they are working on a STIX templates so this type of information can be easily distributed among threat intelligence sharing partners.

Should "Disinformation Analysis Service" be part of a CTI Service Catalogue?
With the creation of the AM!TT Framework it definitely makes it easy to integrate this type of information in Threat Intelligence Platforms and helps push the completeness, objectiveness, accurateness and contextualization of the final threat intelligence product up. But currently it might be a bit too early to consider this type of service as most CTI functions are still in their "threat feed" stadium of maturity and widespread disinformation among Cyber Threat Intelligence sources has not yet have emerged. Nevertheless looking at the obvious trends within the world it will only be a matter of time until this Disinformation Analysis Service integration shift's from a "could have" to a "should have".

In recent years there has been a shift within the SIEM landscape with regards of the focus of monitoring not only on-premise devices but also those devices and services in the cloud. This shift has created a need for SIEM solutions to be either on-premise and partially in the cloud (collector in the cloud) or fully in the cloud (cloud native SaaS SIEM solutions). In this article I want to shine light on the differences of on-premise and Cloud native SIEM's and specifically have a closer look at the most forth coming of cloud native SIEM solutions "Microsoft Azure Sentinel".

Comparison table between On-Premise SIEM and Cloud Native SIEM.

Critical Highlights when using a cloud native SIEM.

• There will probably be no log data portability within the native cloud
• Content portability might be made partially possible with SOC Prime's Tool to convert content
• Putting extended trust in the vendor since the customer has no access to the backend or the physical machines he puts most of his trust in SOC2/3 certifications and assurance from the vendor.
• Forced upsell other SaaS services of the same vendor might require a license upgrade to be able to offer the full log data content ingested to the cloud native SIEM. This might push costs up significantly.
• Limitation of administrative configuration due to it's SaaS nature the solution might not serve your wide range of security use cases.
• You need to be aware on what type of data you are sending to the cloud and in which cloud region (PII, or other sensitive data types) to avoid compliance violations.
• Masking, Obfuscation, Anonymization, and Tokenization will be key methods to control the data you send and secure into the cloud.
• Vendor lock-in The more you will integrate, the more mature the content and the more you use other services of the same vendor the more you become locked-in the specific cloud provider.
• You don't know actually where your data is residing at any point of time within the cloud.

Advantages when using a cloud native SIEM

• Patching and updates happen automatically (you're never behind patching).
• High availability and scalability is assured.
• General data-center security is of high quality (for the major vendors at least).
• Price per usage allows for quickly scaling out or scaling down to reduce costs.
• Insight in your actual usage cost per period.

Conclusion - Cloud Native SIEM
The cloud native SIEM market is growing rapidly, it has alot of pro's and some con's. It also requires the users to be much more mindful on what type of data will be send to the SIEM. Bottom line: it's not for everybody but it is definitely a new evolution of SIEM.

Closer look at Microsoft Azure Sentinel

Within the cloud market there are currently 3 major players (yes there are other but for this analysis I've focused on the top 3). Each have a form of cloud-native SIEM proposition.

• Amazon AWS - Security Hub (If you google "AWS SIEM" you sometimes also get ELK Stack or detective)
• Google Cloud - Chronicle Backstory (there is limited information available on this solution)
• Microsoft Cloud - Azure Sentinel (most forth coming SIEM player of the 3)

Doing a simple google trends query results shows the following results:

Since Azure sentinel was the most forth coming of the three vendors and had the most easily accessible information available of the three I've taken a closer look at Microsoft Azure Sentinel.

When getting into a new product it's handy to make an overview of available resources for the use of this solution. Similar like I've done for other vendors in the past like in this article.

Documentation - https://aka.ms/asi_documentation
Youtube - https://www.youtube.com/channel/UCGTUbqE3SJiLgtvWjIkSQuQ
Webinars - https://aka.ms/SecurityWebinars
Free Training - https://aka.ms/SentinelNinjaTraining
Conference - https://techcommunity.microsoft.com/ (ignite recap 2019)
Product Blog - https://aka.ms/azuresentinelblog
Content Development - https://github.com/Azure/Azure-Sentinel
Support - https://aka.ms/AzureSentinelMicrosoft
Feature Reqs - https://feedback.azure.com/forums/920458-azure-sentinel
Trial Version - https://azure.microsoft.com/en-us/services/azure-sentinel/
User Community - https://aka.ms/AzureSentinelCommunity
Reddit Community - https://aka.ms/AzureSentinelReddit
Twitter - https://aka.ms/AzureSentinelTwitter
LinkedIN - https://aka.ms/AzureSentinelLinkedIn
Telegram User Chat Groups - https://t.me/AzureSentinelSIEM / https://t.me/AzureSentinelSIEMFEED

With some SIEM vendors in the past information was not always available in each category, in this case there is information freely available for every aspect of this categorization. This shows a open and sharing attitude towards its user community (similar like in the QRadar community).

Before I dive in to my findings on the solution I need to highlight that:
- I've analyzed this through a ArcSight, QRadar (and a bit of Splunk/ELK) background
- I did the Azure Sentinel Level 400 Ninja self study training found here
- I ran a trial instance of Azure Sentinel where I created 1 log source, 1 rule, 1 dashboard, 1 report, 1 automation based on this 1 log source to gain practical experience

This is not a complete list, but a initial impression of findings thus far.

Conclusion - Azure Sentinel
Microsoft Azure Sentinel has not been existence as long as the on-premise solutions but they have made big steps forward within a short period of time by leveraging existing Microsoft services, open source software like logstash, fluentD and the existing CEF format for ingestion of logs. Although still in it's early maturity stage, thus far it looks as the most promising of the three cloud vendors.

I recently created a blog post where I proposed the OODA loop as part of a central SOC strategy. I've received lots of positive feedback from others on the usage of this model in this particular blog post, therefore I will compound onto that post as i have in the past used the OODA extensively for designing Security Operation Center's (SOC) processes and metrics. The way I used OODA during that time was with a higher generalization version within the context of a SOC. The usage of the model within the SOC context will function as a compass for Cyber Security leaders to judge any situation quickly and strategically. Thus enabling the leader to respond quickly when he sees a "Strategic Inflection Point" on the cyber battlefield.

What is a Strategic Inflection Point?

"A strategic inflection point is a time period when an organization must respond to disruptive threats in the threat landscape effectively or face deterioration. An inflection point, in general, is a decisive moment in the course of some entity, event or situation that marks the start of significant change."

Once a strategic inflection point is observed by the cyber security leader there is a possibility for a "coup d'oeil"

What is a COUP D'OEIL?

"The coup d'œil refers to the ability to discern at one glance the tactical advantages and disadvantages of the terrain"

Another practical definition might be:

"A selective projection of past elements into the future, in a new combination as a course of action that might or might not fit your previous goals, with the personal commitment to follow through and work out the details along the way" - William Duggan

In essence: doing things differently

When the emergence of a strategic inflection point and coup d'oeil plays out, the need for cyber response to do something different quickly comes up. To be able to do things differently on the cyber battle field and implement change quickly within the SOC, it is required to make use of an adaptive type of life-cycle that is flexible to change on short notice, for example: OODA or SCRUM.

Why SCRUM?
Within the SOC there has always been "light" development activities like: Use Case Development (any form of Detection rules for SIEM, EDR, IDS, IPS etc.) but generally it is quite rare to see this treated as a official development activity. With the emergence of SOAR tooling and automation within the SOC, python developers are getting more and more required within the team. This in turn will also increase the development workload that is associated with SOAR and automation.

Generally people working in SOC's do not have a extensive development background and creating these development processes and working like a developer do not always comes naturally, therefore it's important to properly teach SCRUM (and use a scrum master) within the team before starting of with such initiatives.

Putting PDCA, OODA and SCRUM together
In this article I will propose to cyber security leaders an idea to put services in three major camps PDCA, OODA, SCRUM. The reason why I make this proposal is because some cyber security leaders still treat everything as one big ISMS with PDCA controls that periodically get reviewed, this does not work in a SOC that is adaptive by nature and tries to model the threat landscape proactively on a daily basis.

What are the differences between the three?
In the following table i've tried to capture the difference between the three.

To visualize this concept I've created the following diagram where the key life-cycles are integrated:

Critical Note: There are definitely other services within Security that do development (like within IAM) but i left these out of scope for this article, as my main focus is SOC.
Critical Note2: Threat hunting has two forms: 1. hypothesis based (PDCA) and 2. CTI Validation Based (OODA) didn't really work in this model unfortunately

To go a little bit more in detail on OODA and it's alignment of potential sub processes within the SOC, the following model was created:

For the development processes within a SOC they will be aligned to a micro increment within SCRUM.
Critical Note: Please interpret this as a increment of a sprint that is backlog driven (as in the normal scrum process).

Now I have shown the alignment of the traditional SOC processes with OODA and SCRUM life-cycles. Following this I want to show the value of using OODA as a framework to derive metrics from inside a SOC.

What does the OODA Loop really want?
If you look at the cycle closely you can derive two competing priorities on every OODA iterative loop:

1. Faster iterations of the loop
2. Higher quality iterations of the loop

Higher quality generally means more time spend on the activities thus slowing down the loop. This can only really be countered with automation to again speed up the loop. Speed and Quality are in this case on a tension field with each other.

To go deeper on what these OODA loop steps mean for a SOC, I've created the following diagram to explain it's desires for the SOC:

Using this as a framework for designing metrics for your SOC, one can start determining metrics aligned with the processes and the life-cycle. In the following example I've combined the development and the operations processes in one view to measure performance.

Critical Note: These metrics can be diversified by measuring per time period, in relation to each other or overall quarterly trend.
Critical Note2: Depending on your preference and organizational context one might put more emphasis on Quality or more on speed focused metrics.

Conclusion
Using OODA and SCRUM as lifecycle processes within an organization's cyber security program, keeps things A. Simple, B. Agile and C. Allows for quicker and more qualitative response during a strategic inflection point and coup d'oeil of emerging cyber threats in the fast-changing environment of the organization.

The last couple of years Threat Intelligence Platforms (TIP) have been increasingly more popular in many global Security Operation Centers (SOC). With this technology there comes a unique value that can be provided to Cyber Security Services within an organization. With the support of a TIP platform and a Cyber Threat Intelligence-informed focus it allows to be combined into a "Cyber Threat Intelligence Program" which provides Intelligence (as a process and product) to inform decisions within a series of cyber security services of the organization. Within this blog post I illustrate how that value might look like including some critical factors.

Why have a Cyber Threat Intelligence Program?
A. Cyber Threat Intelligence (CTI) helps with the collection and analysis of information about threats and adversaries. Producing threat models that provide an ability to make knowledgeable decisions for prediction, preparedness, prevention, detection, hunting, response and forensic actions against various cyber-attacks.
B. Cyber Threat Intelligence (CTI) focuses on threat modeling, supporting leadership to evaluate and make informed forward-leaning strategic, tactical, and operational decisions on existing or emerging threats to the organization.
C. Cyber Threat Intelligence (CTI) helps the organization's to identify and mitigate various business risks by converting unknown threats into known threats and helps in implementing various advanced and proactive defense strategies
D. With the constant innovative TTPs used by threat actors, cyber threats are becoming major risks to any business sector. To thwart these threats, it is important for the organizations to incorporate and leverage actionable Cyber Threat Intelligence (CTI) to strengthen their existing security posture.

What are popular Cyber Threat Intelligence (CTI) strategies?
As a general start point, the organization should develop their Cyber Threat Intelligence (CTI) Strategy based on their business risk levels and regulatory, compliance or business requirements. Popular words used in common literature when it comes to CTI might include:

The first three seem to suggest that CTI is the primary driver for making decisions within it's cyber security organization. I believe this is the wrong perception and focus should be shifted to using intelligence to inform policy not drive it.

"The role of intelligence is to inform the decision-making process, support the policies, and provide knowledge and decision advantages for the policy maker" - Amanda J. Gookins

This was also of my argument with publishing the SPEED Use Case Framework where I highlighted that a threat-centric biased approach is risky and should be augmented with:

"You will never reach your destination if you stop and throw stones at every dog that barks." —Winston Churchill

In the following diagram I made an attempt to visualize this core concept:

What must be highlighted before starting a Cyber Threat Intelligence program is that there should be a foundational core SOC context in place to be able to profit of the value of a Cyber Threat Intelligence Program:

1. Established Security Incident Management process.
2. Established Core SOC technologies (Example: SIEM, SOAR, EDR, IDS, IPS).
3. Established Technologies should be able to receive and apply automated Indicator of compromise (IOC's) feeds.

To illustrate more in detail the spectrum of CTI's business value, the following diagram is created:

Critical points:

• This is an over-simplification of the types of CTI, in reality the implementation of these types may vary per organization.
• Within the literature of SANS and EC-Council Operational and Tactical is swapped around (i suspect this has to do with the military origin of most of these conceptual frameworks.) Due to my background primarily in business i flipped these around to make it more logical for myself (and generally the business crowd I present to)
• SANS talks about Strategic, Tactical and Operational, but EC-Council also talks about Technical CTI for the sake of simplicity this has been left out of the diagram.

Conclusion:
A Cyber Threat intelligence-informed SOC strategy is highly beneficial for your cyber security organization in terms of combating targeted cyber threats but do not forget that it's CTI job to inform policy not create it.

The last few years within the Cyber Security Operations Center (SOC) Domain, several new technologies having been trending that enhance SOC capabilities. In particular I want to talk about EDR (Endpoint Detection & Response) in combination with SOAR and SIEM.

This technology (EDR) enables the organization to collect and correlate very intimate details of an endpoint within the organization's network. It also provides a response capability that provides instant mitigation and forensic functionality on the endpoint itself (gives the SOC "teeth" to bite into the incident).

EDR helps the SOC mitigate and investigate much quicker when it comes to cyber security incidents. Still one of the most important key KPI's measured within security operations centers is the time from detection to eradication of cyber security incidents.

Within some SOC builds there is still intense focus on the SIEM and making sure massive volumes of logs are on-boarded inside the tool. This in turn requires a relative amount of time spend followed by a series of use cases being badly configured which gives rise to the following time consuming issues:

   A. Flood of alerts to Analyze
   B. Extensive time spend on Manually Escalating to the right team
   C. Time consuming and limiting capabilities for mitigating the potential threat on the endpoint directly*

Therefore I would like to propose an alternative OODA-Driven SOC Strategy to building or expanding SOC capabilities within an organization. Instead of focusing on the Traditional SOC Strategy with on-boarding log sources, focus on Integration and Quickly responding to cyber security incidents.

How does the OODA Loop apply to a SOC?

The OODA Loop is an agile iterative learning and operations cycle used in the military and the cyber security domain. More information about this model is on the wiki: https://en.wikipedia.org/wiki/OODA_loop . Below here you can see the OODA loop translated to general activities associated with building and running a SOC.

Traditional SOC Strategy vs. OODA-Driven SOC Strategy

What is the difference between Traditional SOC Strategy vs. OODA-Driven SOC Strategy?

Key Critical Notes

This proposed OODA-driven SOC strategy comes with some critical notes that should be taken into account before deciding on this strategy.

Time spend estimates compared

These two pie charts attempt to illustrate the 100% time spend by a SOC team in it's build and run activities. The OODA-Driven approach proposes spreading time allocated out evenly over the full cycle, while traditional approaches might stick with an over focus on Observe and Orient.

Time spend over 6 Month period time

The following diagram tries to illustrate that with a "log source onboarding focus" you end up spending a lot of time manually handling incidents through analysis and response. While focusing on "OODA Automation" will provide more free time to increase capabilities overtime.

How do EDR, SOAR and SIEM fit in?

The following diagram attempts to illustrate the integration between, SIEM, SOAR and EDR following the OODA-Driven SOC strategy.

Conclusion

The main point I have tried to make in this article is that: investing less in SIEM and more in EDR and SOAR (a balanced approach across all three) will provide more room for reducing the overall time of the: "Detection till eradication" KPI through the means of automating the OODA Loop with SOAR and EDR tooling.

With the emergence of SOAR technologies within the Security Operations domain it is clear that this technology has provided great value to departments swamped with tons of alerts that need to be analyzed (the so-called alert fatigue).

Unfortunately buying a SOAR technology will not simply tackle the problem of alert fatigue directly out of the box. To be able to connect an alert to an automated playbook there needs to be a case by case review of use cases within the SIEM before it can be efficiently and effectively connected with a playbook (this requires a mature Use Case Lifecycle Management and Use Case Framework). For optimal automation there are also several other contextual variables that need to be considered before choosing the right escalation playbook that rely on an existing mature IT organization.

The key SOAR distinctions that users should be aware of before venturing into a SOAR project:
1. SIEM Use Case Categories, Use Cases or SIEM Rules are mapped to incident categories and these categories are then mapped to playbooks.
2. Three types of playbooks
     a. Manual playbooks (a series of manual tasks)
     b. Semi-Automated playbooks (a hybrid of automated and manual subtasks)
     c. Fully-Automated playbooks (completely automated)
3. Four types of Automation
     a. Defensive Automation (anything that tries to prevent the threat or risk)
     b. Forensic Automation (anything that tries to retrieve additional evidence)
     c. Offensive Automation (anything pro-active that tries to investigate an asset)
     d. Deception Automation (anything that retrieves or adjusts deception tools)
4. Three different categories of action
     a. Enrichment (adding additional CMDB, CTI or environment data)
     b. Escalation (e-mail, ticket escalation, chatops communication)
     c. Mitigation (the changing of configuration on devices)

These distinctions I have captured in relation to SIEM in the following Diagram.

This provides the SIEM-SOC Automation architecture where we can derive requirements for the deployment of a SOAR solution. These critical success factors and requirements are:

1. Successful automation architecture requires good foundational IT organization
     a. Updated and accurate CMDB
     b. Network hierarchy and their criticality
     c. Data Classification
     d. App Criticality
     e. User Criticality
     f. SLA Ticket Classifications
     g. Top Critical Applications List
     h. Clear Security Incident Ticket Categories
     i. Security Incident Management process
2. Key automation success lies in SIEM integration, Use case Lifecycle Management and Use Case Framework
     a. A SOAR solution that can integrate very intimately with your SIEM solution
          i. Pull additional correlated logs from an alert from the SIEM
          ii. Map every field from the alert to a SOAR case field
          iii. Ability to map SIEM severity levels to SOAR severity levels
          iv. SIEM Alert Timestamps become extremely important when escalating and measuring SLA performance on a SOAR solution make sure these are also left in-tact.
     b. A Mature Use Case Lifecycle Management process
          i. Allows for Additional “automation integrations Priority List” next to the Use Case and log source onboarding priority list.
     c. A Use Case Framework with a clear structure
          i. Having naming conventions that allow mapping of use case category level, Use Case level or Rule specific level playbooks
          ii. Having a clear categories of use cases to group entire categories to playbooks for efficient and effective automation.

In the following example a use case category and naming convention of the SPEED Use Case Framework is mapped against an example use case flow from SIEM to SOAR providing insight into the inter-dependencies of both systems.

Conclusion
Implementing a SOAR solution relies on a series of matured services within the existing IT organization and the Success of a SOAR automation project will highly depend on these maturity levels. Specifically, for the SIEM where Integration, Use Case Lifecycle Management and Use Case Framework need to be fully matured before venturing into a SOAR solution.

It is generally very hard to find an organization to have all proposed requirements of these fully matured inside their IT organization and on top of that, being able to do an automated API call and get all the information needed for an automated playbook.

This in turn gives rise to the new generation cloud-native SIEM and SOAR solutions that are based inside the API-centric cloud architecture and easily can enrich, escalate and mitigate any security issues within its environment.

This conclusion provides insight into the future of A.I. for Cyber security (machine learning, Machine Understanding and Machine Action) within an IT infrastructure. This will be the organic evolutionary growth path of SIEM and SOAR co-existence within the Security Operations context.

With this article I've tried to provide insight into why SOAR Success heavily depends on key existing foundations within the IT organization and critical SIEM dependency. If you liked what you've read you can always connect with me on Linkedin:

What is a Use Case Framework?
A Use Case Framework is an analytical tool that has a series of cyber security related distinctions which are translated into a directory structure (or categories) that facilitate the organization of cyber security detection rules. The objective of building a Use Case Framework is to better protect the organization’s valuable assets by designing and developing detection use cases using a holistic approach that connects (with always newly emerging) regulatory, compliance and threat requirements. The framework provides more granular control over its detection coverage and ongoing development.

UPDATE: I have updated the framework with Splunk implementation example (v1.1)

Downloads:
SPEED Use Case Framework v1.1.pdf
ArcSight ARB Package.arb (just the rule directories)
QRadar Bundle Package.zip (just the rule directories)
ELK Elastalert Bash Script.sh (just the rule directories)

Note: this is all licensed under Creative Commons Zero license. Do what you want with it.
https://github.com/correlatedsecurity/SPEED-SIEM-Use-Case-Framework

You can connect with me on LinkedIN if you appreciate my work: https://www.linkedin.com/in/jurgenvisser/

Why a Use Case Framework?
• To have a holistic “frame of reference” where detection use cases can be categorized into.
• To quickly see where your use cases are lacking and need more attention (blind spots).
• To facilitate a phased approach of expanding new use cases based on a large variety of inputs and priorities (Use Case Roadmap).

What are the Key “SPEED Use Case Framework” differentiators?
A. Vendor neutral
B. Separate from the Use Case Lifecycle Management.
C. Agile and Flexible (can be changed later-on)
D. Simple and clear by design.
E. Addresses Qualitative and Quantitative Threat modelling requirements from the Cyber Threat Intelligence (CTI) team.
F. Specific Naming conventions allowing easier integration with SOAR Playbook categorizations.

What is the Added value by the SPEED Use Case Framework?
Clear Location for log source monitoring use cases
Location for generic Threat actor Threat modeling using the kill-chain
Location for threat modeling threat actors like “APT1” using the kill-chain
Key Distinctions between Threat intelligence types
Key Distinction between Attacker-centric and Defense in depth model
Very clearly defined naming conventions that are consistent all over the framework

What Can I do to implement the SPEED Use Case Framework?
1. Start with a Initial SIEM installation (or existing SIEM installation)
2. Disable All Rules (or disable those who you don’t actively use)
3. Structure Rule Directories
4. Determine Implementation Criteria and a Use Case Framework
5. Start implementing and migrating out-of-the-box Use cases to a chosen Use Case Framework with corresponding implementation criteria.

Examples of the directory structure implemented in some popular solutions: ArcSight ESM QRadar SIEM ELK Elastalert Splunk - Security Essentials App