Thanks Duncan. Just a counterpoint to your second point, the âLockheed Martin Cyber Kill Chainâ just represents the stages of the cyber attack lifecycle in the same way the ODNI Cyber Threat Framework (Required for USG per OMB last year)
and the NSA/CSS Technical Cyber Threat Framework (DoD side) both have Stages of the cyber attack lifecycle as Layer 1 of their frameworks (along with the adversary objectives at Layer 2, actions to achieve the objectives as Layer 3, and indicators for actions
as Layer 4). These are designed to provide consistent categorization and characterization of the threat event using a common 4 layer cyber lexicon. Moving to the NIST 800-160 vol 2 App I resiliency effects replaces the DoD centric 6 effects Lockheed Martin
used in their course of action matrix that came from the 2006 DoD Information Operations effects.
Best,
Shawn
Shawn Riley
Chief Visionary Officer &
Technical Advisor to the CEO
DarkLight, Inc.
Email: shawn@darklight.ai
From: duncan sfractal.com <duncan@sfractal.com>
Sent: Monday, April 22, 2019 8:15 AM
To: Shawn Riley <shawn.p.riley@darklight.ai>; Brule, Joseph M <jmbrule@radium.ncsc.mil>; dave.lemire <dave.lemire@g2-inc.com>; Romano, Jason D <Jason.Romano@gd-ms.com>
Cc: 'openc2-lang@lists.oasis-open.org' <openc2-lang@lists.oasis-open.org>
Subject: OpenC2/IACD/NIST 800-160/F2F
My first point is I do not think OpenC2 breaks IACD so Iâm changing the email title on this thread.
My second point is I was never against the investigate/mitigate/remediate commands. I was against calling them âeffects-based commandsâ since it confused at least some people besides myself (to me, âdenyâ is just as âeffects-basedâ as âmitigateâ),
and I still maintain âLockheed Martin Kill Chainâ is a military-oriented terminology that I personally donât think adds anything to the conversation (but Iâm happy to be overruled) since we kept arguing âtype of commandâ details that were documentation issues.
The arguments didnât affect the known use cases in any way. We didnât just remove the âeffects-basedâ nomenclature, we removed all the classification of commands into types. They are just commands. We should focus on what makes vendor-agnostic interworking
possible, not argue how to arrange the documentation. If we need more commands, make use-cases, and add them.
My third point is really several points on how to move forward.
- I propose the IC-SC at the face-to-face have agenda time on the relationship to IACD, and documenting it (maybe an FAQ?). I personally donât think OC2 breaks IACD, but at least one
person thought so either it does, or there is a misunderstanding. Either way, we should document the relationship of OC2 to IACD. This will avoid misunderstandings in the future, and/or show us issues we need to fix.
- I propose the IC-SC at the Face-to-Face have agenda time on the relationship of OC2 to NIST 800-160 in relation to the points Shawn brings up, and to document whatever comes of the
discussion which may include (but is not limited to) something in an FAQ, potential use cases someone may want to contribute, and/or further work items.
- I propose at some point we open the door to more use cases. We know are at the creeping stage and still need to walk/run/fly. I am not sure the F2F is the proper point to do it but
I could live with it if people make contributions. My preference would be to wait on v1.1 of the language spec until v1.0 made it thru the wickets (ie wait until after the next TC meeting where hopefully we will make a v1.0 Committee Spec. My worry is starting
v1.1 while V1.0 is still in flight and confusing everyone. But if we kept it to use cases weâd like to work on next (ie donât start adding commands to language spec, just make use cases that use the commands youâd like to see), then we could probably make
it work.
- Shawn â Even if you canât attend F2F (side note â I canât either so I can relate), you can still make a âDark Lightâ subdirectory in
https://github.com/sparrell/openc2-lsc-usecases and put in usecases you would like to see handled. The TC works on contributions â we need people to contribute what they want to see handled so we
can figure out how to handle it.
- Because of my desire to avoid dorking 1.0, I have not yet filled-in the sFractal usecases I had started way back when. I believe several of them apply to this thread. Eg 09.Interdomain
is US Government (ie The Small Business Administration) telling sFractal what to mitigate without telling them how to do it (since I have no intention of giving the USG the details of my network).
- I propose at some point (again I think post-1.0, ie wait 1 month, but I can live with anything) we open the issue of âmulti-functionâ devices and how we will handle them. We think
we have designed the language in a way that allow this, but we need more use-cases/examples/working code to validate.
- I propose at some point (ditto previous opinions on post-1.0) we open the issue of âcompoundâ (ie beyond âatomicâ) commands/playbooks/etc. Although a separate topic, this is probably
conflated enough with the previous bullet (multi-function) that we will probably need several use-cases to tease out which goes with what.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
From: Shawn Riley <shawn.p.riley@darklight.ai>
Date: Monday, April 22, 2019 at 9:20 AM
To: Joseph Brule <jmbrule@radium.ncsc.mil>, "duncan@sfractal.com" <duncan@sfractal.com>, Dave Lemire <dave.lemire@g2-inc.com>,
Romano Jason <Jason.Romano@gd-ms.com>
Cc: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
Hi Joe,
While I try to make all the TC and SC meetings, I am not able to attend the Face to Face. Iâm not flying into BWI until Wednesday evening for Integrated Cyber. Below is a simple paragraph on why weâre using an effects-based approach in
our effort but it is probably more important for us since knowledge engineering derived AI expert system understands the meaning of these effects and can use them for reasoning and inference.
We use the NIST 800-160 vol 2 App I cyber resiliency effects as a standardized vocabulary for stating claims or hypotheses about the effects of cyber mission assurance decisions on cyber adversary behavior. The different effects represent
the goal of the defenderâs cyber mission assurance decisions. Cyber mission assurance decisions include choices of cyber defender actions, architectural decisions, and selections and uses of technologies to improve cyber security, resiliency, and defensibility
(i.e., the ability to address ongoing adversary activities). The vocabulary enables claims and hypotheses to be stated clearly, comparably across differentassumed or real-world environments, and in a way that suggests evidence that might be sought but is independent
of how the claims or hypotheses might be evaluated. The vocabulary can be used with multiple modeling and analysis techniques, including Red Team analysis, Blue Team analysis, game-theoretic modeling, attack tree and attack graph modeling, and analysis based
on the cyber attack lifecycle (also referred to as cyber kill chain analysis or cyber campaign analysis).
Best,
Shawn
Shawn Riley
Chief Visionary Officer &
Technical Advisor to the CEO
DarkLight, Inc.
Email:
shawn@darklight.ai
From:
openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org>
On Behalf Of Brule, Joseph M
Sent: Monday, April 22, 2019 6:59 AM
To: Shawn Riley <shawn.p.riley@darklight.ai>; 'duncan sfractal.com' <duncan@sfractal.com>; dave.lemire <dave.lemire@g2-inc.com>;
Romano, Jason D <Jason.Romano@gd-ms.com>
Cc: 'openc2-lang@lists.oasis-open.org' <openc2-lang@lists.oasis-open.org>
Subject: [openc2-lang] RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
All,
These discussions are interesting, but I need to ask (actually I need to insist) that we do these on open OASIS channels such as the email distribution list, github issues or whatever. There has been more than
one occasion where a discussion started and bloomed on an email thread and we do NOT want to do this in a vacuum.
Shawn, we do have a face to face coming. Jason and Toby are the co-chairs of the LSC and I am running point on organizing the agenda. You care ot bring it up?
VR
Joe B
From: Brule, Joseph M
Sent: Monday, April 22, 2019 8:50 AM
To: 'Shawn Riley' <shawn.p.riley@darklight.ai>; duncan sfractal.com <duncan@sfractal.com>; dave.lemire <dave.lemire@g2-inc.com>
Subject: RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
It is not quite fair to say that only the government guys understood the effects based commands. Cisco introduced the actual terms (investigate, mitigate and remediate) and McAfee implemented all three of them
in an earlier iteration of the language description document. (This is pre-OASIS days). The âgovernment guysâ understood and agreed with the notion of effects based, but the general consensus among the TC was that we prune out the actions that do not have
a use case associated with it. The logic being that it is a heck of a lot easier to add an action in version 1.X or 2.0 that it is to deprecate an action (or anything else for that matter) later. I personally was not thrilled with how aggressively the actions
were pruned, but we moved onâ
VR
Joe B
From: Shawn Riley <shawn.p.riley@darklight.ai>
Sent: Saturday, April 20, 2019 7:53 AM
To: duncan sfractal.com <duncan@sfractal.com>; Brule, Joseph M <jmbrule@radium.ncsc.mil>; dave.lemire <dave.lemire@g2-inc.com>
Subject: [Non-DoD Source] RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
Iâm quite surprised to hear that only the gov guys understood âeffects basedâ given that itâs been popular in the 2010 Intelligence-Driven Computer Network Defense paper by Lockheed Martin. Every organization who talks about the âkill chainâ
has already bought in to âeffect basedâ since the heart of the intelligence-driven defense concept is looking at the kill chain in the context of your cyber defense technologies that can have different effects on the adversary as they moved through time. So
ANY organization using a kill chain or cyber effects lifecycle is already doing âeffects-basedâ courses of action as itâs that much part of the intelligence-driven defense concept introduced in 2010. However these standards efforts are normally the âsecurity
engineersâ who build, configure, etc rather then the âsecurity scienceâ who does the analysis and really understand concepts like intelligence-driven defense which has used âeffects basedâ courses of actions for 9 years now. As such, I found engineer donât
understand the terms because they donât work with it like the analysts and investigators do. Letâs put it this way, Iâve not seeing anyone using the cyber kill chain and not doing effects based courses of action in the last 9 years so Iâm quite surprised by
your comment.
Shawn
Shawn Riley
Chief Visionary Officer &
Technical Advisor to the CEO
DarkLight, Inc.
Email:
shawn@darklight.ai
From: duncan sfractal.com <duncan@sfractal.com>
Sent: Saturday, April 20, 2019 2:44 AM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>; Shawn Riley <shawn.p.riley@darklight.ai>; dave.lemire <dave.lemire@g2-inc.com>
Subject: Re: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
And to be clear on âeffects basedâ, only the gov guys understood those terms. Much of the objection was to the terminology(I think all commands are effects based), not objecting to inter-iacd-function eg a command from decision making to
sense making. The whole purpose of IACD is to split into functional blocks and the purpose of openc2 is all C2. But we have to creep before walking so initial focus is on firewalls and other tech doing the âactingâ. We kicked the van down the road on multifunctional
consumers
iPhone, iTypo, iApologize
From: Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Friday, April 19, 2019 8:32 PM
To: 'Shawn Riley'; dave.lemire; duncan sfractal.com
Subject: RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
If I understand what you wrote correctly (and I believe I do) then the short answer is yes and for the first half of your scenario, we actually have demonstrated it using a COTS orchestrator (albeit with an old
version of the speck). My guys have not prototyped the second half of your scenario. I ALMOST had funding to have a company do the entire scenario you described, but on the eleventh hour I had the proverbial rug pulled out from under me.
One of my colleagues at APL was adamant in that she wanted distributed analytics supported and she would periodically slap me around when we diverged.
I do have to give credit to Duncan Sparrell from s-fractal on this one. He dug his heels and insisted that we use the terms âproducerâ and âconsumerâ vice âorchestratorâ âactuatorâ. There is no reason that
an orchestrator cannot receive AND/OR send openc2 commands. The use of producer and consumer keeps it generic and avoids binding with specific blocks in the iacd framework.
That was clear as mudâ
From: Shawn Riley <shawn.p.riley@darklight.ai>
Sent: Friday, April 19, 2019 3:19 PM
To: dave.lemire <dave.lemire@g2-inc.com>; duncan sfractal.com <duncan@sfractal.com>; Brule, Joseph M <jmbrule@radium.ncsc.mil>
Subject: [Non-DoD Source] RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
Just to make sure Iâm clear, if I generate an OpenC2 message output with the Action(s) and Target and any execution options (providing they match the specification) I should be able to send that OpenC2 message from my decision-making solution
to an acting orchestrator which would in turn use itâs technology integrations to carry out the action requested with the target? I can then have my other cognitive playbooks go look for evidence of the actionâs effect on the adversary to measure the actions
effectiveness and provide the feedback to improve decision-making.
Shawn Riley
Chief Visionary Officer &
Technical Advisor to the CEO
DarkLight, Inc.
Email:
shawn@darklight.ai
From: Shawn Riley
Sent: Friday, April 19, 2019 12:25 PM
To: Dave Lemire <dave.lemire@g2-inc.com>; duncan sfractal.com <duncan@sfractal.com>; Brule, Joseph M <jmbrule@radium.ncsc.mil>
Subject: RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
One of the âCalls to Actionâ from my January Tech Talk at NSAâs Emerson III on AI-Driven Logical Argumentation in Active Cyber Defense was on mapping NIST 800-160 vol 2 Resiliency Effects to OpenC2 response actions to make sure this is
was a community mapping and not a single vendor mapping. The âlogical argumentationâ part comes the Cognitive Playbooks automating the standardized 8 stages of Argument-Driven Inquiry used in science and engineering classes since human intel analysts (to include
threat intel analysts) are suppose to use logical argumentation as called out in the analytic standards section of ICD-203. We needed to ensure that security automation supported the analytic standards of the humanâs they are mimicking.
Iâm still very much interested in having a community mapping from Effects to OpenC2.
Shawn
Shawn Riley
Chief Visionary Officer &
Technical Advisor to the CEO
DarkLight, Inc.
Email:
shawn@darklight.ai
From: Shawn Riley
Sent: Friday, April 19, 2019 11:57 AM
To: Dave Lemire <dave.lemire@g2-inc.com>
Cc: duncan sfractal.com <duncan@sfractal.com>; Brule, Joseph M <jmbrule@radium.ncsc.mil>
Subject: RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
Weâre actually selecting courses of action based on the adversary action (STIX Attack Pattern / ATT&CK Technique / CTF Action), the assets involved, and the desired NIST 800-160 vol 2 defined (App I) Resiliency Effect(s) that I briefed
at the Fall Integrated Cyber event last year. Itâs the reason behind the Cyber Effects Matrix we use which is the essences of intelligence driven computer network defense since it frames adversary actions with the cyber defense solutions that can achieve the
different effects. Iâve attached a copy of the Cyber Effects Matrix from my briefing last year to give you a better idea. This might have also contributed to the confusion.
Effects are a key part of decision making because if you donât know what effect the action is having you donât know what evidence to look for to measure the effectiveness of the response action taken and effects are mapped to what impact
they have on the defenseâs risk (reduced impact and/or reduced occurrence).
I also recorded a video on Cyber Resiliency Effects on Adversary Activities on my Talking SoS (Science of Security) video series. That provides an overview of the resiliency effects (intended effect, expected result, effect on risk, example,
and evidence). https://youtu.be/qcAgVtr6rbI
Shawn
Shawn Riley
Chief Visionary Officer &
Technical Advisor to the CEO
DarkLight, Inc.
Email:
shawn@darklight.ai
From: Dave Lemire <dave.lemire@g2-inc.com>
Sent: Friday, April 19, 2019 11:44 AM
To: Shawn Riley <shawn.p.riley@darklight.ai>
Cc: duncan sfractal.com <duncan@sfractal.com>; Brule, Joseph M <jmbrule@radium.ncsc.mil>
Subject: Re: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
Shawn, Duncan, Joe,
I think some of my words may have been mis-interpreted. If I recall, what I told Shawn was that the concept of "effects based" commands had been removed; these are commands where
a higher element sends a more general command to a lower element, which then decides how to achieve the effect based on the assets it has available. To the best of my knowledge no use cases have been documented for that. Shawn's interpretation, which I hadn't
intended, was that we'd disconnected deciding from acting, which I don't think is the case. The Language Spec certainly allows for the case where a command is send from (Producer A) to (Consumer / Producer B) to (Consumer C). We just don't specifically describe
situations where the command from B -> C differs from / is more detailed and specific than the command from A -> B.
It absolutely is the case that OpenC2 v1.0 is focused on atomic commands, so if the need is to implement a course of action (which I think equates to the "Action Playbook" Shawn
describes), the decision function would have to send a sequence of atomic OpenC2 commands rather than sending a complete course of action in a single step.
Dave
--
David P. Lemire, CISSP
HII Mission Driven Innovative Solutions (HII-MDIS, formerly G2, Inc.)
Technical Solutions (A Division of Huntington Ingalls Industries)
OpenC2 Technical Committee Secretary
OpenC2 Implementation Considerations SC Co-chair
Contractor support to NSA
Email: dave.lemire@g2-inc.com
Work (301) 575-5190 | Mobile (240) 938-9350
On Fri, Apr 19, 2019 at 1:37 PM Shawn Riley <shawn.p.riley@darklight.ai> wrote:
Itâs worth keeping in mind that there are Cognitive Playbooks that capture and encode the deterministic reasoning and inference of human domain experts that are used by the Knowledge Engineering derived AI that is focused on knowledge integration and then there are Action Playbooks that capture and encode the mechanistic actions of human domain experts that are used by the Security Orchestators that is focused on technology integration.
We have over 100 Cognitive Playbooks just for Windows events alone to detect, verify, and explain adversary behavior (NSA/CSS Technical Cyber Threat Framework â Adverary Actions, with associated Objectives during different Stages of the cyber attack lifecycle) as well as nearly 100 W3C OWL2 Ontologies for different sensors, taxonomies (CVE, STIX, CASE, CAPEC, MITRE ATT&CK, ODNI Cyber Threat Framework, NSA/CSS Technical Cyber Threat Framework, etc), and reasoning and inference rules to support automated inference of from the knowledge in the ontologies.
In the output Steps of the Cognitive Playbook we have a STIX v2.x Step to produce STIX threat intelligence reports, a OpenC2 step to produce OpenC2 commands, weâre working on a step for the Cyber-investigation Analysis Standard _expression_ (CASE) which is part of the Unified Cyber Ontology being developed by the DFIR community with strong support from the EC3, DC3, and NIST.
Shawn
Shawn Riley
Chief Visionary Officer &
Technical Advisor to the CEO
DarkLight, Inc.
Email: shawn@darklight.ai
From: duncan sfractal.com <duncan@sfractal.com>
Sent: Friday, April 19, 2019 11:24 AM
To: Shawn Riley <shawn.p.riley@darklight.ai>; Brule, Joseph M <jmbrule@radium.ncsc.mil>
Cc: Dave Lemire <dave.lemire@g2-inc.com>
Subject: Re: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
It does sound like there is confusion.
One confusion may be over âcourse of actionâ vs âatomic actionâ and whether the âmaking a course of action from a sequence of atomic actionsâ is the role of the decision maker or the actuator in IACD. Personally I assumed âdecision makerâ but it hasnât been discussed in OpenC2 yet because we kicked the âplaybookâ discussions down the road under the premise we needed to get the atomic actions before we could put them together. Iâll let the NSA answer for itself, but I was under the impression they desired OpenC2 to remain âatomicâ. I may have misunderstood whether that was just at that time (ie do atomic-walk before playbook-fly) or they had other plans for standardizing playbooks. I donât think the TC has discussed it yet because as I said, we were focused on atomic actions (ie the steps in the playbook) before we got into whether the control flow of playbooks was a logical extension to OpenC2 or belonged in other already existing standards (eg STIX). In any case, I donât see any conflict with what you were trying to do. If you have an orchestrator to orchestrator use case (which is clearly within scope and has been discussed), we can work to make a custom actuator profile with the standard as it exists today, and then make it standard if (ie âun-customizeâ it) if that makes sense. If that proves technically infeasible, then we have a problem we will need to solve because clearly the intent is to cover all C2 situations.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
From: Shawn Riley <shawn.p.riley@darklight.ai>
Date: Friday, April 19, 2019 at 1:06 PM
To: "duncan@sfractal.com" <duncan@sfractal.com>, Joseph Brule <jmbrule@radium.ncsc.mil>
Subject: Re: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
Dave Lemire. Who said that the use case for sending courses of action from a decision making solution to an orchestrator was removed.
We have been in discussion with Keith Willett and Michael Herring and for the last 6 months have been collaborating with the team who created the NSA/CSS Technical Cyber Threat Framework for consistent categorization and characterisation of threat events during automation of sense-making and decision-making via the research directorate.
Shawn
From: Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Friday, April 19, 2019 10:57:51 AM
To: Shawn Riley; Duncan Sparrell
Subject: RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
OK, I confess that I am confused. When you say âDaveâ, which Dave said this?
OpenC2 is a language used to express a command (an action, the associated target and optional actuator/ options). We intentionally defined the scope as the atomic command as it resides at the egress of whatever issued the command or the ingress of whatever is going to execute the command.
Having said that, then the phrase âthe use case for communicating from decision-making to acting with OpenC2 was removed from the OpenC2 specificationâ makes no sense to me. There is nothing to preclude some âanalytic engineâ from sending one or more openc2 commands to an orchestrator because the language spec simply defines openc2 producers and consumers and does to put restrictions on the participant. I agree that this is a potential issue. Can you point to the section of the specifications that precludes a use case where the analytics can communicate an openc2 command?
Out of curiosity, who is the NSA ACD team?
VR
Joe B
From: Shawn Riley <shawn.p.riley@darklight.ai>
Sent: Friday, April 19, 2019 12:35 PM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>; Duncan Sparrell <duncan@sfractal.com>
Subject: [Non-DoD Source] OpenC2 Spec Breaks IACD and NSA ACD Frameworks
Joe & Duncan,
In a conversation with Dave during the OpenC2 IC SC earlier this week I learned something I was not aware of. When I shared that DarkLight was focused on the IACD piece of sense-making and decision-making so we could make decisions about what action we wanted the orchestrator to take and then send OpenC2 commands to the orchestrator, I was informed that the use case for communicating from decision-making to acting with OpenC2 was removed from the OpenC2 specification. By removing this support from the OpenC2 specification it has made Acting (orchestration) a standalone silo and doesnât accept command and control information from a higher level source like a solution focused on sense-making and decision-making. I keep thinking about this and if acting remains disconnected from sense-making and decision-making then OpenC2 reinforces what the cybersecurity community refers to as playing âwhack-a-moleâ with response actions but moving from human speed to machine speed whack-a-mole. It sends the message to the community to focus on response actions rather than determining the root cause or the why behind the threat or risk detected in your automation strategy. This shouldnât be the message weâre sending with OpenC2 as it just undermined the last 4 years of IACD community that has solutions dedicated to sense-making and decision-making that are not orchestrators.
Iâm also pretty certain that not having command and control between decision-making and acting that it breaks the conceptual models of both IACD and the NSA Active Cyber Defense team.
Iâve reached out to both the IACD leadership and the NSA ACD team to make them aware of this issue that came to light earlier this week. The only reason our company is part of the OASIS OpenC2 effort is because weâre one of the decision-making solutions that has been a part of the IACD community since 2016 when NSA came to us to say we had to be part of the IACD community.
Best,
Shawn
Shawn Riley
Chief Visionary Officer &
Technical Advisor to the CEO
DarkLight, Inc.
Mobile: (314) 695-2602
Email: shawn@darklight.ai
This e-mail (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. If you received this e-mail in error, please delete it from your system without copying it and notify sender by reply e-mail so our records can be corrected.