Select Page

A good old-fashioned AI expert system is designed to integrate knowledge into a knowledge-base using knowledge engineering and then mimic how human domain experts apply their experience and expertise working with the integrated knowledge. The integrated knowledge in an expert system’s knowledge-base is called a knowledge graph.

“While machine learning (ML) is exceptional at analyzing data to create models that make predictions, recognize patterns, and automate decisions, it lacks human reasoning capabilities,” the Forrester analysts write. “In 2019, enterprise AI mavericks will rediscover knowledge engineering and digital decisioning platforms to extract and encode inferencing rules and build knowledge graphs from their expert employees and customers. ML’s strength is data. Knowledge engineering’s strength is human wisdom. Used together, enterprises can dramatically accelerate the development of AI applications.”

Gartner Identifies Five Emerging Technology Trends That Will Blur the Lines Between Human and Machine. One of these emerging technologies is ‘Knowledge Graphs’ which is the integrated knowledge inside the knowledge-base of good old-fashioned AI. Gartner shared the following:

Emerging technologies require revolutionizing the enabling foundations that provide the volume of data needed, advanced compute power and ubiquity-enabling ecosystems. The shift from compartmentalized technical infrastructure to ecosystem-enabling platforms is laying the foundations for entirely new business models that are forming the bridge between humans and technology.

This trend is enabled by the following technologies: Blockchain, Blockchain for Data Security, Digital Twin, IoT Platform and Knowledge Graphs.

Digitalized ecosystem technologies are making their way to the Hype Cycle fast,” said Walker. “Blockchain and IoT platforms have crossed the peak by now, and we believe that they will reach maturity in the next five to 10 years, with digital twins and knowledge graphs on their heels.”

Let’s look at a threat hunting example of hunting for adversary Tactics, Techniques, and Procedures (TTPs). Out of all things you can hunt for, adversary TTPs are considered one of the toughest to find according to the Pyramid of Pain and human threat hunting experts. (Pyramid of Pain by David Bianco http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html)

Let’s assume we want to be able to find all the known-known adversary TTPs that have been identified in MITRE Enterprise ATT&CK which covers 12 Tactics (adversary objectives), 244 Techniques (adversary actions), and each Technique could have 1 or 50+ different Procedures (adversary’s step by step workflow) they use for completing that specific technique to accomplish their objectives. https://attack.mitre.org/

Let’s assume in our hypothetical example that all those known-known MITRE Enterprise ATT&CK TTPs can be found in the following data sources identified by the Threat Hunting Project. https://www.threathunting.net/

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Hunting Procedures Indexed by Data Required

Anti-Virus Logs

Finding Known-Bad in Antivirus Logs

ZEKE (Bro) NSM Logs

RDP External Access

C2 via Dynamic DNS

Finding the Unknown with HTTP URIs

Producer-Consumer Ratio for Detecting Data Exfiltration

Finding C2 in Network Sessions

DNS Query Logs

C2 via Dynamic DNS

Host Dumps (RAM, Registry, Filesystem, Processes, etc)

Comparing Host Images/Memory Dumps to Known-Good Baselines

RAM Dumping

Comparing Host Images/Memory Dumps to Known-Good Baselines

NTFS Extended Attribute Analysis

Search for Rogue Listeners

Shimcache/Amcache

Autoruns Analysis

Windows Driver Analysis

Windows Prefetch Cache Analysis

Windows Service Analysis

HTTP Proxy Logs

Beacon Detection via Intra-Request Time Deltas

HTTP User-Agent Analysis

C2 via Dynamic DNS

Finding the Unknown with HTTP URIs

HTTP Server Logs

Internet-Facing HTTP Request Analysis

Finding Webshells

Network Sessions (Netflow or similar)

Producer-Consumer Ratio for Detecting Data Exfiltration

Finding C2 in Network Sessions

Process Creation Audit Logs

Suspicious Process Creation via Windows Event Logs

Webshell Behavior

Lateral Movement Detection via Process Monitoring

Finding Malware Process Impersonation via String Distance

Identify Suspicious Command Shells

Windows Event Logs

EMET Log Mining

Suspicious Process Creation via Windows Event Logs

Psexec Windows Events

Detecting Lateral Movement in Windows Event Logs

RDP External Access

Windows Lateral Movement via Explicit Credentials

Privileged Group Tracking

Webshell Behavior

Lateral Movement Detection via Process Monitoring

Other

Checking How Outsiders See You

Tool Renaming

Finding Golden and Silver Tickets

Using W3C standardized knowledge representation languages like OWL2 we can create knowledge models called ontologies for the different data sets, taxonomies, and frameworks we want to use for threat hunting.

Ontologies are 1 of 4 common types of knowledge models used in IT. The 4 types of knowledge models from simplest to the most complex are Dictionaries, Taxonomies, Thesaurus, and Ontologies. Of these 4 types of knowledge models, ontologies support more advanced reasoning than the more simple knowledge models as well a being able support semantic interoperability where different data sets identify the same ‘thing’ by different names. For example STIX Attack Patterns = MITRE ATT&CK Techniques = ODNI Cyber Threat Framework Actions = NSA/CSS Technical Cyber Threat Framework Actions. Ontologies can also be used in backwards compatibility mode (thesaurus mode, taxonomy mode, and dictionary mode) so while ontologies are the most complex to create, they also support the widest number of use cases and automated reasoning capabilities.

Common components of ontologies include:

  • Individuals: instances or objects (the basic or “ground level” objects)
  • Classes: sets, collections, concepts, types of objects, or kinds of things.
  • Attributes: aspects, properties, features, characteristics, or parameters that objects (and classes) can have
  • Relations: ways in which classes and individuals can be related to one another
  • Function terms: complex structures formed from certain relations that can be used in place of an individual term in a statement
  • Restrictions: formally stated descriptions of what must be true in order for some assertion to be accepted as input
  • Rules: statements in the form of an if-then (antecedent-consequent) sentence that describe the logical inferences that can be drawn from an assertion in a particular form
  • Axioms: assertions (including rules) in a logical form that together comprise the overall theory that the ontology describes in its domain of application. This definition differs from that of “axioms” in generative grammar and formal logic. In these disciplines, axioms include only statements asserted as a priori knowledge. As used here, “axioms” also include the theory derived from axiomatic statements.
  • Events: the changing of attributes or relations

As an example of well known cybersecurity axioms that could be encoded in an ontology for the good old-fashioned AI expert system to understand and apply when reasoning over the knowledge in the knowledge-base, consider the Diamond Model of Intrusion Analysis paper which identified 7 axioms for the humans using the diamond model to understand the fundamental nature about threats. See the linked article from one of the authors of the diamond model to learn more. http://www.activeresponse.org/diamond-model-axioms/

Now that we’ve created W3C standardized, shareable ontologies for the data sets, dictionaries, taxonomies like OASIS STIX or MITRE Enterprise ATT&CK, etc that we want to use for threat hunting, we’re ready to capture the experience (know how / expertise) of human domain experts in threat hunting for TTPs. We do this in good old-fashioned AI expert systems like DarkLight using shareable cognitive playbooks that support deterministic reasoning and deductive inference. (NOTE: these are NOT to be confused with orchestrator ‘acting’ playbooks that focus on automating mechanistic response actions.)

Good Old-Fashioned AI (aka Knowledge Engineering AI) supports both ontology-based inference and rules-based inference using another W3C standardized language called SWRL. A core architecture piece of a good old-fashioned AI expert system is an inference engine that can make inferences to derive new data from data that you already know. For example, if I know this fact and this fact from the data set(s) then I can deduce (inference) this new fact from the knowledge in the knowledge-base.

Threat hunting is essentially an investigation where human domain experts investigate the data set(s) for evidence of adversary behavior such as detecting, verifying, and explaining adversary TTPs. One standardized investigation method used in both science and engineering is called argument-driven inquiry which leverages the well known Claim Evidence Reasoning framework. Argumentation claims (definition, fact, value, policy, cause & effect) represent what is known, evidence is how we know that, and the reasoning is why the evidence supports the claims being made.

We can automate argument-driven inquiry using cognitive playbooks. I’ve previously posted an article describing how the standardized 8 stages of argument-driven inquiry can be applied during the creation of cognitive playbooks. That article is here: https://www.linkedin.com/pulse/automating-argument-driven-inquiry-shareable-cognitive-shawn-riley/

Let’s look at an example of a cognitive playbook for detecting MITRE Enterpise ATT&CK Technique T1086 PowerShell. Cognitive playbooks can leverage sub-playbooks that perform repetitive tasks like gathering contextual information about the user and device involved in the adversary behavior or for determining the NIST impact assessment based on the type of adversary behavior and the enterprise assets (user/device/etc) involved along with what parts of the business/mission those assets support. In the below image we can see one of the 100+ cognitive playbooks in DarkLight for detecting MITRE Enterprise ATT&CK Techniques has been selected from the playbook manager. These cognitive playbooks look for behavioral indicators of the different procedures used by the adversaries for the ATT&CK techniques rather then looking for simple indicators of compromise such as hashes, IP addresses, and/or domain names.

By automating the argument-driven inquiry process the cognitive playbooks will follow the step by step workflow and thinking of the human domain expert who created the cognitive playbook and produce a fully transparent, explainable result in the form of a logical argument. The results of cognitive playbooks are also fully reproducible.

The logical argument results of the cognitive playbook are assembled together into mini semantic knowledge graphs as shown below. (NOTE: this results graph is only showing about 10% of the full results. The primary nodes and edges are shown to simplify the amount of information being presented.)

At the bottom of the below graph you can see the Windows Event log analyzed by the T1086 PowerShell cognitive playbook we used earlier which identified and asserted a behavioral indicator for the T1086 PowerShell technique. The sub-playbooks identified and asserted the contextual information about the enterprise assets involved in the adversarial behavior detected.

The cognitive playbook then uses the facts about the type of adversary technique that was detected and verified along with the facts about the enterprise assets involved and what parts of the business / mission those assets support to infer (deduce) all the facts in the green area at the top of the knowledge graph.

These inferences include assessing the NIST impact, inferring this is an incident based on the NIST impact, inferring the STIX Attack Pattern (T1086), the MITRE ATT&CK Tactic (Execution), the ODNI Cyber Threat Framework (CTF) Stage of the cyber attack lifecycle (Presence) as well as the NSA/CSS Technical Cyber Threat Framework (NTCTF) adversary Objective (Execution) and Stage of the cyber attack lifecycle (Presence), finally, the cognitive playbook inferred recommended courses of action from the encoded MITRE Enterprise ATT&CK knowledge as well as inferring any STIX Courses of Action that were automated to have some effect(s) on the adversary behavior detected.

Last year the Teradata Corporation wrote an article about ‘AI without Machine Learning’ which can be found here: https://www.teradata.com/Blogs/AI-without-machine-learning

In the article Teradata Corporation shared:

If you insert a small amount of knowledge into a machine, you can call it an engineering product. But if you instil a sufficiently large amount of knowledge such that the machine makes better decisions than a human, what do you call it then? For example, if you take hundreds of medical doctors and each spends hundreds of hours detailing correlations between symptoms and disease, you have created something impressive. What if you then pack that knowledge into an easy-to-use machine, which will output a likely diagnosis based on the symptoms you input? Is that an AI?

Well, yes, it is. In fact, today this type of AI we sometimes call GOFAI – an acronym which stands for “good old-fashioned AI”. GOFAI was based on a human-understandable symbolic system. It is an AI without machine learning.

GOFAI is used in two ways today:

 

  1. Supplementing the work of machine learning in creating a full AI product
  2. Producing an AI solution on its own, without any machine learning

The real power of GOFAI expert systems is the ability to capture not just the expertise of one human domain expert but the expertise of many different experts so that the AI expert system has the combined knowledge of all those experts integrated into the AI and can mimic how the human domain experts apply and use the integrated knowledge in the knowledge-base to solve complex problems.

Consider the threat hunting example and if we were to gather up 10 threat hunting experts for each of the 10 data sets we called out earlier in this article, and each expert created 10 cognitive playbooks for detecting adversary TTPs in the data sets they are working on. The result would an AI expert system with 1000 cognitive playbooks for detecting adversary TTPs using the combined, integrated experience of the human domain experts who created them. The integration of knowledge and human domain expertise is exactly why this type of good old-fashioned AI is called an ‘expert system’.

At DarkLight, we’ve been focused on building a good old-fashioned AI expert system for active defense as part of the Integrated Adaptive Cyber Defense (IACD) Community (https://www.iacdautomate.org/aboutiacd) that is focused on mimicking the integrated knowledge and experience of 4 cyber defense roles identified in the National Initiative for Cybersecurity Education (NICECybersecurity Workforce Framework (NICE Framework), published by the National Institute of Standards and Technology (NIST) in NIST Special Publication 800-181.

Just like the threat hunting example we used in this article, we would do the same for other active defense areas such as:

  • Threat Intelligence Consumption where we want to organize what is known from threat intelligence into integrated threat intelligence knowledge using the ontologies and how to apply and use the integrated threat intelligence using cognitive playbooks created by threat intelligence human experts. The more knowledge integrated and the more cognitive playbooks added to integrate the experience and know how of human domain experts the more powerful the expert system becomes.
  • Incident Response where we want to organize the incident response investigation information using standardized ontologies like the Cyber-investigation Analysis Standard Expression (https://caseontology.org/) which is a profile of the Unified Cyber Ontology (https://github.com/ucoProject/UCO) that is being developed by the Digital Forensics and Incident Response (DFIR) community. We also want to create cognitive playbooks that capture the experience and expertise of human incident response experts. If we can detect adversary behavior with threat intelligence comsumption or threat hunting, we should then apply the integrated incident response knowledge to respond and recover from the detected, verified, and explained adversary behavior (TTPs).
  • Threat Intelligence Production where we want to be able to produce threat intelligence to capture and share information about the adversary behavior that was automatically detected, verified, and explained through threat hunting automation, threat intelligence consumption automation, and incident response automation. The ontologies allow the AI expert system to understand and use the knowledge represented in the ontologies such as using OASIS’s STIX v2 to encode machine readable threat intelligence that can be shared via TAXII with communities of trust. The cognitive playbooks can capture the experience and expertise of human threat intelligence analysts to automate their step by step workflow and applied knowledge for producing threat intelligence.
  • Effects-based courses of action is another area we are focused on using ontologies and cognitive playbooks. Effects-based courses of action are the essence of what Lockheed Martin described in their Intelligence-Driven Defense white paper a decade ago. Rather then it being a human-driven model in a spreadsheet, good old fashioned AI allows us to create ontologies to represent the cyber attack lifecycle (MITRE ATT&CK, ODNI Cyber Threat Framework, NSA/CSS Technical Cyber Threat Framework, etc) as well as an ontology for a standardized set of resiliency effects such as the resiliency effects in the Cyber Resiliency Engineering Framework (NIST 800-160 vol 2 App I). Once we model the cyber attack lifecycle and cyber resiliency effects, we can then encode different courses of action in DarkLight’s cyber effects matrix so the course of action is mapped to both adversary behavior and what effect(s) the course of action will have on the adversary behavior. We can create cognitive playbooks to encode the human domain expert’s experience and expertise in selecting courses of action that can be recommended or automatically taken based on the detected, verified, and explained adversary behavior, the enterprise assets involved in the adversary behavior, and the desired effect(s) of the courses of action.

The ability to organize integrated adaptive cyber defense knowledge into the knowledge-based using ontologies and integrate the experience and expertise of human domain experts using cognitive playbooks into a good old-fashioned AI expert system is powerful, not to mention being fully transparent and explainable.

Ontologies can be updated as data sets, taxonomies, frameworks, etc mature and the cognitive playbooks can be updated with increasing amounts of human cyber defense experience / expertise as the defender’s tradecraft knowledge increases. In DarkLight the ontologies, the mapping (reify) configuration of the raw data to the ontologies, and the cognitive playbooks are all shareable through simple import and export functions. Just like you can share STIX based threat intelligence or cyber defense signatures like Yara, Snort, or SIGMA, good old-fashioned AI enables cyber defense organizations to share knowledge models and the human domain expert’s experience and expertise in applying and using that knowledge to solve complex cyber defense problems.

Good old-fashioned AI expert systems for active defense enables organizations to integrate their silos of cyber defense information into integrated adaptive cyber defense knowledge while increasing the speed and scale of applying human domain expertise and experience in a way that is 100% transparent and explainable by using shareable cognitive playbooks with fully reproducible results.