Dave,
I agree with your point about the device profile being more implementation centric, that can (hopefully) be accomplished with a combination of implementation guidance and actuator profiles.
Specifically for suite-of-documents, I have found oauth to cover something on those lines, where there is a core framework, and multiple other specs on top of it. See
https://www.oauth.com/oauth2-servers/map-oauth-2-0-specs/ . It has a very similar approach where the core leaves a lot of implementation details unspecified, and then builds specific implementation
considerations as layer on top of the core.
I would imagine the bootstrap to be a similar layer on top of the core framework, where the implementation guidance will evolve specs around how to accomplish the areas unaddressed by the core spec. At a minimum bootstrap
, transport, authC and authZ seem to be the logical next layers on top of the core specs, and should likely be driven the IC-SC, in consultation with the language and the actuator sub committees.
-Sudeep
From: Dave Lemire <dave.lemire@g2-inc.com>
Date: Wednesday, May 16, 2018 at 6:13 AM
To: "Das, Sudeep" <Sudeep_Das@McAfee.com>
Cc: "Brule, Joseph M" <jmbrule@radium.ncsc.mil>, "duncan@sfractal.com" <duncan@sfractal.com>, TC OpenC2 <openc2@lists.oasis-open.org>
Subject: Re: [openc2] RE: OpenC2 document structure
|
CAUTION:
External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
Sudeep,
I think you've explained where / how a device profile might fit in our overall strategy quite well; thanks. While we don't yet have any worked or in-progress examples of implementation guidance
documents, I do think there might be some conceptual overlap, since that's the document where it's envisioned to address transport and security conventions for a particular implementation / communications environment. If we hit the target on those, then in
my mind a device profile is a pretty straight-forward combination of a selected implementation guidance document + the actuator profiles supported by the device. And I acknowledge I may be oversimplifying.
As part of our overall strategy to leverage existing standards, I also always look for worked examples of our concepts like these, so I'd ask: can you point to any other standards that have a
similar "suite of documents" approach?
IMO, at present we're more in need of implementation guidance documents than a bootstrap process, but I certainly don't have objections to you working on the latter. Right now anything that helps
to fill in the overall "mosaic" for OpenC2 seems useful.
David P. Lemire, CISSP
OpenC2 Technical Committee Executive Secretary
OpenC2 Implementation Considerations SC Co-chair
Contractor support to NSA
Email: dave.lemire@g2-inc.com
Office: 301-575-5190 / Mobile: 240-938-9350
On Tue, May 15, 2018 at 3:03 PM, Das, Sudeep <Sudeep_Das@mcafee.com>
wrote:
Hi Joe,
Appreciate the detailed thoughts on this. Would take this opportunity to share some of my thoughts around the points
that you mentioned. So far,discussions have focused on the actuator and orchestrator, and the fundamental premise has been that actuators communicate to orchestrators directly; and actuator profile provides all necessary information to the orchestrator to
enable C&C. This, of course works fine.
A device profile, the way I see it, is metadata about an logical openc2 “agent” on a device. Having an agent that encapsulates
transport, authc, authz, integrity, whatever ; and provides a single service interface to all actuators on the device has logistical benefits. My suggestion is to view the ecosystem as orchestrator
à device
à actuator semantics vis-à-vis the orchestratoràactuator semantics.
This separation of concerns is highly useful from a practical standpoint. At the same time, collapsing the device and actuator into one as a special case gives us what we have right now, as a direct orchestrator
à actuator semantics
Specific to the example that you mention
>The ACME company may have a product that has routing function, DIT analytic function, static filtering
functions etc. Is the proposal that we standardize an ACME profile? My ‘instinct’ states that a bottoms up approach is better. Look at the device profiles and identify the ‘functional blocks’ to standardize and strive for a disjoint sets. Devices are
likely to have multiple actuator profiles.
No… we standardize a device profile that makes it possible to publish the capabilities of an “agent” on the device. For example, the
transport (port/protocol etc) , authc/authz (oidc, mtls, user/pass), any logical device id/address etc. And we standardize the actuator profile(s) the way we are doing currently; but include additional information / semantics for it to use the device profile
information and to bind to the agent on the device. This is in line with devices having multiple actuator profiles.
For the other point about bootstrap and the draft profiles, I think we need to both. While we have traction on the profiles, it would
be good to flesh out the bootstrap process. I can volunteer to put up an initial proposal towards bootstrapping an actuator into an openc2 ecosystem.
Hopefully this sounds logical and makes sense, glad to be part of the conversation…
Regards
-Sudeep
|
CAUTION:
This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
Mr. Das,
I read your “OpenC2 abstractions
and implementations”. Thank you, what a clear and concise document and read through your email and (with minor discrepancies) agreed with your points.
Despite the fact that I agree with essentially everything you bring up, interestingly enough I do not see the necessity of the so called ‘device
profile’ within the TC, though I do hope that we see vendors and mission owners aggressively produce ‘device profiles’.
Here is my logic or lack thereof:
- The Language Specification defines the ‘actions’ (what you are doing) and targets (what you are doing it to). The language spec accommodates
the extension (look at section 2.2.6)
- The actuator profiles (note plural) defines the subset of actions and targets that are meaningful IN THE CONTEXT of the functional
actuator and provides a means to define options that refine how a particular action is to be done. (case in point, if we tell a DAR analytic to scan a file, do we want to refine the scan command to distinguish a static signature vs a heuristic vs machine
learning via a naïve Bayesian classifier?
- The implementation specifications (again, note the plural) define the integration/ implementation IN THE CONTEXT of a particular cyber
ecosystem.
I really want to make this clear: We (in general the TC, in particular the AP-SC) need to create an actuator profile writing guide, and I hope
that the mission owners and vendors produce ‘device profiles’. Here is where we might have a disagreement: I do not think we should ‘standardize’ the device profile. The ACME company may have a product that has routing function, DIT analytic function, static
filtering functions etc. Is the proposal that we standardize an ACME profile? My ‘instinct’ states that a bottoms up approach is better. Look at the device profiles and identify the ‘functional blocks’ to standardize and strive for a disjoint sets. Devices
are likely to have multiple actuator profiles.
Regarding your points ‘b’ and ‘c’ which you also discussed in your document, I agree in principle that we would want a ‘basic’ stack implemented
so we can bootstrap the device when it first comes on for purposes of registration etc. In fact, if I read your paper correctly, we should look into whether or not we can have an inband initialization/ negotiation process. I do in fact agree, but my question
to you is, at this point we only have two draft profiles (neither of which have been submitted to the TC yet) and do not have a draft implementation spec yet. Should we leverage some of the existing work being done in the repositories now? Or should we pursue
the bootstrapping first?
Your email (and Duncan and Dave) really stimulated thoughts, thank you!
VR
Joe Brule
From a practical and implementation standpoint, I think Duncan’s points are spot on. My reasoning would be
-
The device is the one that has the actual hardware and software capabilities for letting an actuator carry out its function
-
In practice, one would “enroll” a device into an openc2 ecosystem, and there will be one or more actuators on that device.
-
It seems a more cleaner separation of concerns if actuator interactions were with the device, and the device interacts with the orchestrator/transport/messaging/authentication. There are significant gains to interoperability
in this paradigm. A provider can just to device management, and another vendor can just to actuators, and they will be able to work together with greater ease than if every single actuator had to include logic to manage enrolment/transport/authC/authZ
-
The number, type, purpose and functionality of actuators is unbounded. That of devices is finite. Custom actuators that interact with well defined and finite device profiles have a more streamlined approach towards
an ecosystem play.
Having joined openc2 recently, I have struggled with the “out of scope” nature of key touch points in a command and control ecosystem.
I have tried to summarize some of the big picture out of scope items at https://docs.google.com/document/d/1XdGkHvgHn7JXJYnlyqNOqx29QabZVFHLi-T7D4rF4OE
, inspired mostly by Danny Martinez’s previous outline on open questions and items.
Back to the primary question:
Yes, a device profile makes sense. Not just that, it’s likely imperative that such a thing existed. Semantically, a device profile would
include the so called out of scope items, as well as one or more actuator profiles
-Sudeep
|
CAUTION:
This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
|
> "...a meaningful difference in the types of content needed
between an actuator profile and a device profile ..."
My reason for asking was just that question - do we need
something that aggregates the transport and actuator profiles for a device. Is AP sufficient? My gut is that AP is not sufficient but I'll happily drop concept of device profile if it is. It came out from the fact in all my examples there is a device I'm describing
by listing the specs involved. If only humans need DP for understanding purposes, then drop the concept. If something needs that info in realtime to make a decision, then we do need it. Maybe it's nothing more than the response to a particular query and device
profile is just a term to help humans know what a device does.
> "what APs and transport specs a device conforms to is
a configuration activity that's outside the scope of OpenC2"
I would argue it's inside the scope if we really want to
get eventually to responding at cyber speed. If humans have to get involved with configurations then it will not be cyberspeed. For some (clearly not all) applications, introspection (ie the automagically figuring out what functionality exists, or could exist
at what cost) will be needed.
> "And if the device vendor is really bringing a new function
to the table, isn't that a request for a change to the L-Spec to incorporate a new action(s)?"
We have literally hundreds of security functions we do not
yet profiles for; yet real products exist. To my knowledge, we have the actions we need for all of them. Maybe time will cause us to add something but I maintain we have the vast majority covered and someone could start making AP's for all of them now. I think
it will be hard and take awhile for us to standardize on the 'specification' AP for (pick any one of IDS, IPS, NGFW, URL Filter, Deception, IADM, WebProxy, ...). Yet we we could come up today with the 'extension' AP for a snort-IDS, Palo Alto NGFW, Attivo
Deception, Symantec WebProxy, etc. Ie let's deal with some very explicit profile extensions for specific existing high runner (or low runner, whatever anyone wants to do) devices.
Note my email came about because I yelled at some people
they should be making actuator profiles and the ensuing discussions are what led to this email thread. Partly it was they couldn't look at our stuff and figure out the big picture (hence the document structure questions). And partly it was not knowing where
to start since their 'profile' wasn't one we were working on (hence the extension part of the discussion).
My gut is we (both the vendors and the users doing it for
the vendors who don't do it themselves) should be making lots of 'custom' profiles for anything users are already using in their networks. I don't want people holding back and thinking for example an IDS can't use OpenC2 because we don't have a specification
for an OpenC2 IDS Actuator Profile. You should be able to do a custom extension today. We should be doing it to prove we can. If we can't, then we should fix whatever is wrong. We have some chicken/egg issues and I don't want the slow progress on AP specifications
to impede getting the custom extensions going.
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: Re: [openc2] RE: [Non-DoD Source] [openc2] OpenC2 document
structure
From: Dave Lemire <dave.lemire@g2-inc.com>
Date: Thu, May 10, 2018 12:36 pm
To: "Brule, Joseph M" <jmbrule@radium.ncsc.mil>
Cc: "duncan@sfractal.com"
<duncan@sfractal.com>,
TC OpenC2
<openc2@lists.oasis-open.org>
In response to questions 1 & 2: I concur that Duncan's examples
nicely illustrate the scope of what needs to be defined. I think we can craft some language and a picture or two that can either be included as a standard appendix or placed on the TC's wiki page and pointed to from each document (maybe an item in the informative
references section?). As is usual with me for these sorts of questions, I always wonder if there are other worked examples within OASIS that we could / should emulate.
I submit this layering diagram as a starting point for such
a picture.
I think Question 3 requires more thought and time.
3) does concept of 'device profile' make sense? If so, do we (ie Implementation SC) need to make a document on what an implementer needs
to include (ie how to make a device profile)? Should we write a spec on 'formatting' a device profile (eg it's a json data structure ...)
My basic question is whether there's a meaningful difference
in the types of content needed between an actuator profile (which we've agreed to organize around functions) and a device profile that a vendor might create for one of their products (or perhaps a function(s) within one of their products). It seems to me that
informing a producer what APs and transport specs a device conforms to is a configuration activity that's outside the scope of OpenC2. And if the device vendor is really bringing a new function to the table, isn't that a request for a change to the L-Spec
to incorporate a new action(s)?
David P. Lemire,
CISSP
OpenC2 Technical Committee Executive Secretary
OpenC2 Implementation Considerations SC Co-chair
Contractor support to NSA
Email: dave.lemire@g2-inc.com
Office: 301-575-5190 / Mobile: 240-938-9350
On Thu, May 10, 2018 at 12:15 PM, Brule, Joseph M <jmbrule@radium.ncsc.mil>
wrote:
You are stone cold correct and I like your examples. Openc2 is in fact a suite of documents but that has
not been clearly articulated, most likely for the simple reason that the elements of the ‘suite’ are in progress.
The best way to do this? The approach that makes sense to me is your third option (or
included in each document.) or perhaps a concise summary in each document and point to a reference (which is your first option.)
Now is a good time to bring this up. The Language spec is moving nicely, we almost have a profile and we
reactivated the IC-SC.
I have been involved in several discussions about OpenC2
and this is an attempt to organize some thoughts, document them, and solicit feedback from the wider community.
One issue we need to address is documenting the overall
structure of the documentation for OpenC2. I don't know if this is a separate document, a webpage, or included in each document.
I'm not sure of the correct words to propose so I'm going
to explain by giving examples as background and then I'll discuss the document structure issue.
Let's say I would like to develop some open source software
(which I do) for the first use case I submitted (https://github.com/oasis-tcs/openc2-usecases/blob/master/sFractalConsulting/01.another_user.md)
and I would like to send an openc2 command from SO3 to FW5. For my example I would like FW5 to be an AWS NACL stateless packet filter and I would like SO3 to interface using a HTTPS API. I would like to write the software that would terminate on the Amazon
side of the interface. It would start out 'just mine' but would be submitted to be part of the AWS opensource projects to provide an 'official' OpenC2 interface to AWS NACL's should Amazon agree to the pull request.
I believe there are 3 different specifications we are drafting
that are applicable.
- the OpenC2 Language Specification
- the OpenC2 HTTPS API Transport Specification
- the OpenC2 stateless packet filter Actuator Profile Specification.
As further background to point I'll eventually make, let's
assume AT&T wants to do similar with the second use case they submitted (https://github.com/oasis-tcs/openc2-usecases/blob/master/ATT/02.allow.md)
also for AWS NACL's, but in their case using OpenDxl pub/sub transport and assume we were to create a OpenDxl transport specification (I'll cover the case where we don't later). For their example the 3 specifications would be:
- the Language Specification
- the OpenC2 OpenDxl Transport Specification
- the stateless packet filter Actuator Profile Specification.
Example 3 is just Example 2 where AT&T uses OpenDxl but
the OpenC2 TC decides that there can only be one OpenC2 pubsub transport (I hope they don't, but this is for illustrative purposes) and TC chose OpenDDS over OpenDxl because McAfee hasn't actually made OpenDxl 'open'. In this case the software could be compatible
with:
- the Language Specification
- the stateless packet filter Actuator Profile Specification
but would not be compatible with a transport specification.
I apologize but I have not filled in
https://github.com/oasis-tcs/openc2-usecases/blob/master/sFractalConsulting/11.deception.md
but I will. In this case several security functions are involved and the technology (either cymmetria or attivo) has one OpenC2 Consumer that integrates several OpenC2 Actuator Profiles. Assume for illustrative purposes that we'd standardized all the actuator
profiles for Attivo (example 4) and some, but not all, of the actuator profiles for Cymmetria (example 5).
The example 4 specifications are:
- the OpenC2 Language Specification
- the OpenC2 HTTPS API Transport Specification
- the OpenC2 deception1 (assume we have real functions)
Actuator Profile Specification
- the OpenC2 deception2 Actuator Profile Specification
- the OpenC2 deception3 Actuator Profile Specification
The example 5 specifications are:
- the OpenC2 Language Specification
- the OpenC2 HTTPS API Transport Specification
- the OpenC2 deception1 Actuator Profile Specification
- the OpenC2 deception4 Actuator Profile Specification
- an Cymmetria-provided deception5 Actuator Profile Specification
that "extends" a new security function
If I put myself in the shoes of someone not as involved
as I've been, I do not think we do a good job of explaining how the documents interact and that all these examples are valid. It's also not clear to me whether we need another document that is provided by the implementer of the device in each example (an device
profile?) that specifies what transport and actuator profiles (including extensions) a given device (using term to mean either physical or virtual device) supports. I think this is a very important issue because (1) there are more security professionals that
are NOT intimately involved in OpenC2 and (2) for the foreseeable future there will be more 'extensions' than there are 'standard' actuator profiles.
The questions for discussion are:
1) does the above make sense as valid examples of how the
specifications go together?
2) should there be something explaining the overall structure?
If so, webpage or separate document or in each document?
3) does concept of 'device profile' make sense? If so, do
we (ie Implementation SC) need to make a document on what an implementer needs to include (ie how to make a device profile)? Should we write a spec on 'formatting' a device profile (eg it's a json data structure ...)
iPhone, iTypo, iApologize
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC
that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|