Sent: Monday, April 22, 2019 6:55 AM
To: Brule, Joseph M; 'duncan sfractal.com'; dave.lemire; Romano, Jason D
Cc: 'openc2-lang@lists.oasis-open.org'
Subject: [openc2-lang] RE: OpenC2 Spec Breaks IACD and NSA ACD Frameworks
I would like to know how we can move forward with testing the untested scenario we identified.
Where System A sends an OpenC2 message for an action on System C to System B for System B to coordinate with System C.
System A does sense-making verification and explanation to inform decision-making which decides what actions to take in order to have a desired effect on the threat/risk detected but it not an orchestrator.
System B is an security orchestrator with technology integration with System C
System C is where the actuator is that needs to take the action requested by System A via System B
Thanks,
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 7:27 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
OK, I will put it on the agenda. I know that the ATT guys will have a video conferencing capability set up, so if your schedule permits you can participate remotely for at least that part.
From: Shawn Riley <shawn.p.riley@darklight.ai>
Sent: Monday, April 22, 2019 9:20 AM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>; '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: [Non-DoD Source] 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.