Open Cybersecurity Alliance Architecture

[Adam Montville]

All:

I’d like to draw your attention to some ideas the OCA has been discussing that brings together SCAP/SACM ideas, IACD ideas, and other architectures into an OCA reference architecture that can help that group organize and talk about the work its doing - i.e. what OCA can help enable.

I’d appreciate your perspective on the architecture diagram found at [1] and the issue discussion at [2].

There’s a lot going on in that diagram, but it’s starting to approach the idea of identifying various components required for automating operational security programs in an enterprise.

We can probably get another meeting between the groups to discuss further (i.e. SCAP folks are welcome to join an OCA architecture working group meeting).

Kind regards,

Adam

PS: I know some of the SACM/SCAP type boxes are mis-labeled per our latest architecture draft - the spirit is the same.


[1] https://raw.githubusercontent.com/opencybersecurityalliance/documentation/master/SACM_OCA_IACD.png
[2] https://github.com/opencybersecurityalliance/documentation/issues/2

[Charles Schmidt]

Hi Adam,

Thanks for sharing. I looked over the diagram as well as the associated thread and, well... I'm just lost. Obviously, I am missing a great deal of context, especially with regards to what supposedly is happening within each of the boxes, but it feels like the SCAP architecture could be compatible with this diagram because I think just about any security solution could be compatible with this diagram depending on how boxes and links were defined.

It looks like the lower left (collection) and upper left (repository) elements, connected by the central Integration Service (Manager?) are the most aligned, but the association seems to be mostly conceptual (of only because I'm probably not keyed into the concepts these boxes represent).

How does OCA plan to use this diagram? Is it a map for a technical solution or is it a conceptual outline of capabilities of interest for securing an enterprise? Is it something a solution might conform to, or just a way to place a project within a larger security context?

Sorry I'm not following this better. Maybe you could spend a bit of time briefing on this on the next call (unless you think you could clarify a bit over the mailing list, which would be ideal).

Thanks,

Charles

[Adam Montville]

Hi Charles,

Yes, it’s a busy diagram that actually has several potentially conflicting purposes. The diagram shows various components from at least the following subdomains: threat intelligence, endpoint protection, SIEM, SOAR, infrastructure, vulnerability/compliance/policy (this is where they put SCAP/SACM), OT/embedded, security overlay/consolidators/consultancy. (No, there aren’t any tight definitions around those terms yet.) This covers a wide swath of the organizations already interested in OCA.

The diagram also has the intent to mesh with existing architectural ideas - like SCAP/SACM, IACD, and others that may come up (I know we’ve got a couple of folks looking around in EU/ENISA documents for such ideas as well).

We also wanted that diagram to inform the OpenDXL Ontology effort - what are the various interfaces we might expect to require and in which of the subdomains? This is why you see SCAP/SACM boxes in the light blue. Really, we don’t need to be overly concerned with the other pieces of the diagram, only satisfied that we fit in. Any interactions with other parts of the diagram may come over time. For example, some day it might be the case that our evaluations might take the form of “detection findings” that feed the decision making box, that then feeds into the response action controller, which may in turn tell our manager/orchestrator/application to take some action.

I did point out on a board call yesterday that there are some areas where one subdomain will overlap with another. For example, what the OCA is calling vulnerability/compliance/policy (basically SCAP/SACM) requires state collection, but I imagine that threat hunting and EDR (endpoint detection and response) will also need state collection.

The middle green box that has another box within it might be a little confusing. It’s all OpenDXL - the same communication fabric - and what they wanted to convey is that there’s this fabric-adjacent component that can translate data between the subdomains (this is STIX-Shifter - the other OCA project). So, in some cases, information has no need to flow through such a translation, and in others it does.

Given the ultimate goal of OCA, it makes perfects sense that “just about any security solution could be compatible with this diagram”. That’s actually the idea, only we also want to start identifying overlaps and duplication. 

Let me know if any of that was helpful. I’m happy to try and speak to it on our next call.

Kind regards,

Adam

--
To unsubscribe from this group, send email to scap-dev-endpo...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-endpoint
---
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-endpo...@list.nist.gov.

[Charles Schmidt]

Hi Adam,

Thanks for the clarification. Sounds like I was misunderstanding the intent. Based on what you describe, I agree that I can see SCAP fitting within elements of the diagram. Good to see that we do seem to have a good fit with the OCA landscape.

Charles

On Friday, June 26, 2020 at 8:30:49 AM UTC-5, Adam Montville wrote:

Hi Charles,

Yes, it’s a busy diagram that actually has several potentially conflicting purposes. The diagram shows various components from at least the following subdomains: threat intelligence, endpoint protection, SIEM, SOAR, infrastructure, vulnerability/compliance/policy (this is where they put SCAP/SACM), OT/embedded, security overlay/consolidators/consultancy. (No, there aren’t any tight definitions around those terms yet.) This covers a wide swath of the organizations already interested in OCA.

The diagram also has the intent to mesh with existing architectural ideas - like SCAP/SACM, IACD, and others that may come up (I know we’ve got a couple of folks looking around in EU/ENISA documents for such ideas as well).

We also wanted that diagram to inform the OpenDXL Ontology effort - what are the various interfaces we might expect to require and in which of the subdomains? This is why you see SCAP/SACM boxes in the light blue. Really, we don’t need to be overly concerned with the other pieces of the diagram, only satisfied that we fit in. Any interactions with other parts of the diagram may come over time. For example, some day it might be the case that our evaluations might take the form of “detection findings” that feed the decision making box, that then feeds into the response action controller, which may in turn tell our manager/orchestrator/application to take some action.

I did point out on a board call yesterday that there are some areas where one subdomain will overlap with another. For example, what the OCA is calling vulnerability/compliance/policy (basically SCAP/SACM) requires state collection, but I imagine that threat hunting and EDR (endpoint detection and response) will also need state collection.

The middle green box that has another box within it might be a little confusing. It’s all OpenDXL - the same communication fabric - and what they wanted to convey is that there’s this fabric-adjacent component that can translate data between the subdomains (this is STIX-Shifter - the other OCA project). So, in some cases, information has no need to flow through such a translation, and in others it does.

Given the ultimate goal of OCA, it makes perfects sense that “just about any security solution could be compatible with this diagram”. That’s actually the idea, only we also want to start identifying overlaps and duplication. 

Let me know if any of that was helpful. I’m happy to try and speak to it on our next call.

Kind regards,

Adam

On Jun 25, 2020, at 12:04 PM, Charles Schmidt <schmidt...@gmail.com> wrote:

Hi Adam,

Thanks for sharing. I looked over the diagram as well as the associated thread and, well... I'm just lost. Obviously, I am missing a great deal of context, especially with regards to what supposedly is happening within each of the boxes, but it feels like the SCAP architecture could be compatible with this diagram because I think just about any security solution could be compatible with this diagram depending on how boxes and links were defined.

It looks like the lower left (collection) and upper left (repository) elements, connected by the central Integration Service (Manager?) are the most aligned, but the association seems to be mostly conceptual (of only because I'm probably not keyed into the concepts these boxes represent).

How does OCA plan to use this diagram? Is it a map for a technical solution or is it a conceptual outline of capabilities of interest for securing an enterprise? Is it something a solution might conform to, or just a way to place a project within a larger security context?

Sorry I'm not following this better. Maybe you could spend a bit of time briefing on this on the next call (unless you think you could clarify a bit over the mailing list, which would be ideal).

Thanks,

Charles

On Wednesday, June 24, 2020 at 2:41:35 PM UTC-5, Adam Montville wrote:

All:

I’d like to draw your attention to some ideas the OCA has been discussing that brings together SCAP/SACM ideas, IACD ideas, and other architectures into an OCA reference architecture that can help that group organize and talk about the work its doing - i.e. what OCA can help enable.

I’d appreciate your perspective on the architecture diagram found at [1] and the issue discussion at [2].

There’s a lot going on in that diagram, but it’s starting to approach the idea of identifying various components required for automating operational security programs in an enterprise.

We can probably get another meeting between the groups to discuss further (i.e. SCAP folks are welcome to join an OCA architecture working group meeting).

Kind regards,

Adam

PS: I know some of the SACM/SCAP type boxes are mis-labeled per our latest architecture draft - the spirit is the same.


[1] https://raw.githubusercontent.com/opencybersecurityalliance/documentation/master/SACM_OCA_IACD.png
[2] https://github.com/opencybersecurityalliance/documentation/issues/2

--

To unsubscribe from this group, send email to scap-dev...@list.nist.gov

Visit this group at https://list.nist.gov/scap-dev-endpoint
---

To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev...@list.nist.gov.

[Jason Keirstead]

Hi Charles & team; I just wanted to let you know I am the primary author of the diagram and am lurking on the thread. (long time lurker, first time responder ) :)

First of all - thank you Adam for the extremely accurate positioning here of what we are trying to achieve and the multiple purposes of this work. I just want to add as well, that this diagram should not be considered anywhere near an end-state. I would say it is an early draft, an attempt to create a unified point of view on a few different cybersecurity architectures, using the OCA technology as a unifying factor - to try to bring these somewhat disparate pieces together with an end-to-end viewpoint on cybersecurity.

Very much looking forward to the collaboration and any feedback.

To unsubscribe from this group, send email to scap-dev-endpo...@list.nist.gov

Visit this group at https://list.nist.gov/scap-dev-endpoint
---

To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-endpo...@list.nist.gov.

[Paul Hedges]

As others have said; It appears as though you've missed the configuration standardization and the migration needed on that based on a number of sources on the right.