Architecutre diagram viewpoint

[opencybersecurityalliance]

Architecutre diagram viewpoint

[warrenrjwc]

Thanks for the post, Adam. You bring up some good points in regards to how we want to scope our OCA efforts and where we draw the line. Your thoughts will bring up some good discussion across the PGB and architecture teams. Russ

[swood-tripwire]

Adam, Your approach sounds reasonable to me. The object is two part 1) create something that can be used for communication to the outside world (ergo simplicity) and create something that is a scoping reference to suggest where unsatisfied work lives (not dictate work to be done). I think that your idea is clearly aligned with these objectives.

I have a second question for you. We have had discussions about C2, Open DXL, Stix, etc. These don't strictly show up in the logic that you are advocating. Got any thoughts about how we capture this logic as well? I'm not saying that it has to be a single graphic.

[adammontville]

Thanks @swood-tripwire. Yes, I do have additional thoughts. If I look to what SACM and SCAP 2.0 has been drawing up, we have defined specific architectural roles and therefore have identified a variety of interfaces.

For example, the following describes the intent behind SACM:

      +-----------------+     +--------------------+
      | Orchestrator(s) |     | Repositories/CMDBs |
      +---------^-------+     +----------^---------+
                |                        |             +--------------------+
                |                        |             |  Downstream Uses   |
                |                        |             | +----------------+ |
    +-----------v------------------------v------+      | |   Analytics    | |
    |             Integration Service           <------> +----------------+ |
    +-----------^--------------------------^----+      | +----------------+ |
                |                          |           | |   Reporting    | |
                |                          |           | +----------------+ |
    +-----------v-------------------+      |           +--------------------+
    |  Collection Sub-Architecture  |      |
    +-------------------------------+      |
                           +---------------v---------------+
                           |  Evaluation Sub-Architecture  |
                           +-------------------------------+

Given the above, we see that there is an orchestration role, there is a repository role, there are a variety of downstream uses, and of course collection and evaluation sub-architectures.

Now, imagine we're looking at a configuration management workflow. It shouldn't be a stretch to define configuration-management-specific roles and interfaces that participate in an architecture such as this one.

A more detailed view of the above:

     +----------------------------------------------------------+
     |                    Orchestrator(s)                       |
     +-----------+----------------------------------------------+
                 |               +------------------------------+
                 |               | Posture Attribute Repository |
                 |               +--------------^---------------+
              Perform                           |
             Collection                         |
                 |                       Collected Data
                 |                              ^
                 |                              |
     +-----------v------------------------------+---------------+
     |                    Integration Service                   |
     +----+------------------^-----------+------------------^---+
          |                  |           |                  |
          v                  |           v                  |
       Perform           Collected    Perform           Collected
      Collection           Data      Collection           Data
          |                  ^           |                  ^
          |                  |           |                  |
     +----v-----------------------+ +----|------------------|------+
     | Posture Collection Service | |    |     Endpoint     |      |
     +---^------------------------+ | +--v------------------+----+ |
         |                   |      | |Posture Collection Service| |
         |                   v      | +--------------------------+ |
       Events             Queries   +------------------------------+
         ^                   |          (PCS resides on Endpoint)
         |                   |
     +---+-------------------v----+
     |          Endpoint          |
     +----------------------------+

In the above, we show specific flows with specific information moving through the fabric between the various components that fulfill specific roles (note that one component can play more than one role, and that is by design). This is the level where, as dictated by the convention/semantics conveyed in the interface specification (i.e. an OpenDXL Ontology interface), the various data formats would be known.

Hopefully this makes some sense. Essentially, we could choose to create three levels of diagram. One would be the security program view I conveyed by submitting this issue. The next level down could be the core or foundational roles we expect to support the various workflows demanded by the security program. The next level down could be program-/tool-specific workflow perspectives.

Thoughts?

[swood-tripwire]

Adam, This looks very interesting. I need a day or two to review. I just had something blow up this morning and have to go put the pieces back together. Part of the life of product management. From: adammontville [mailto:[email protected]] Sent: Friday, May 29, 2020 7:35 AM To: opencybersecurityalliance/documentation <[email protected]> Cc: Stephen Wood <[email protected]>; Mention <[email protected]> Subject: Re: [opencybersecurityalliance/documentation] Architecutre diagram viewpoint (#2) [EXTERNAL] Thanks @swood-tripwire<https://github.com/swood-tripwire>. Yes, I do have additional thoughts. If I look to what SACM and SCAP 2.0 has been drawing up, we have defined specific architectural roles and therefore have identified a variety of interfaces. For example, the following describes the intent behind SACM: +-----------------+ +--------------------+ | Orchestrator(s) | | Repositories/CMDBs | +---------^-------+ +----------^---------+ | | +--------------------+ | | | Downstream Uses | | | | +----------------+ | +-----------v------------------------v------+ | | Analytics | | | Integration Service <------> +----------------+ | +-----------^--------------------------^----+ | +----------------+ | | | | | Reporting | | | | | +----------------+ | +-----------v-------------------+ | +--------------------+ | Collection Sub-Architecture | | +-------------------------------+ | +---------------v---------------+ | Evaluation Sub-Architecture | +-------------------------------+ Given the above, we see that there is an orchestration role, there is a repository role, there are a variety of downstream uses, and of course collection and evaluation sub-architectures. Now, imagine we're looking at a configuration management workflow. It shouldn't be a stretch to define configuration-management-specific roles and interfaces that participate in an architecture such as this one. A more detailed view of the above: +----------------------------------------------------------+ | Orchestrator(s) | +-----------+----------------------------------------------+ | +------------------------------+ | | Posture Attribute Repository | | +--------------^---------------+ Perform | Collection | | Collected Data | ^ | | +-----------v------------------------------+---------------+ | Integration Service | +----+------------------^-----------+------------------^---+ | | | | v | v | Perform Collected Perform Collected Collection Data Collection Data | ^ | ^ | | | | +----v-----------------------+ +----|------------------|------+ | Posture Collection Service | | | Endpoint | | +---^------------------------+ | +--v------------------+----+ | | | | |Posture Collection Service| | | v | +--------------------------+ | Events Queries +------------------------------+ ^ | (PCS resides on Endpoint) | | +---+-------------------v----+ | Endpoint | +----------------------------+ In the above, we show specific flows with specific information moving through the fabric between the various components that fulfill specific roles (note that one component can play more than one role, and that is by design). This is the level where, as dictated by the convention/semantics conveyed in the interface specification (i.e. an OpenDXL Ontology interface), the various data formats would be known. Hopefully this makes some sense. Essentially, we could choose to create three levels of diagram. One would be the security program view I conveyed by submitting this issue. The next level down could be the core or foundational roles we expect to support the various workflows demanded by the security program. The next level down could be program-/tool-specific workflow perspectives. Thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOHPWUJWNL6CFO3GERO32CLRT7BZTANCNFSM4NMNYGRQ>.

[JasonKeirstead]

Adam do you have a diagram of this somewhere that could be opened up and annnotated? A SVG or Visio or PPT or Draw.IO or something?     If not I will try to make one.   -Jason KeirsteadChief Architect - IBM Security Threat Managementwww.ibm.com/securityCo-Chair - Open Cybersecurity Alliance, Project Governing Board www.opencybersecurityalliance.org      ----- Original message -----From: swood-tripwire <[email protected]>To: opencybersecurityalliance/documentation <[email protected]>Cc: Subscribed <[email protected]>Subject: [EXTERNAL] Re: [opencybersecurityalliance/documentation] Architecutre diagram viewpoint (#2)Date: Fri, May 29, 2020 11:55 AM   Adam,This looks very interesting. I need a day or two to review.I just had something blow up this morning and have to go put the pieces back together. Part of the life of product management.From: adammontville [mailto:[email protected]]Sent: Friday, May 29, 2020 7:35 AMTo: opencybersecurityalliance/documentation <[email protected]>Cc: Stephen Wood <[email protected]>; Mention <[email protected]>Subject: Re: [opencybersecurityalliance/documentation] Architecutre diagram viewpoint (#2)[EXTERNAL]Thanks @swood-tripwire<https://github.com/swood-tripwire>. Yes, I do have additional thoughts. If I look to what SACM and SCAP 2.0 has been drawing up, we have defined specific architectural roles and therefore have identified a variety of interfaces.For example, the following describes the intent behind SACM:+-----------------+ +--------------------+| Orchestrator(s) | | Repositories/CMDBs |+---------^-------+ +----------^---------+| | +--------------------+| | | Downstream Uses || | | +----------------+ |+-----------v------------------------v------+ | | Analytics | || Integration Service <------> +----------------+ |+-----------^--------------------------^----+ | +----------------+ || | | | Reporting | || | | +----------------+ |+-----------v-------------------+ | +--------------------+| Collection Sub-Architecture | |+-------------------------------+ |+---------------v---------------+| Evaluation Sub-Architecture |+-------------------------------+Given the above, we see that there is an orchestration role, there is a repository role, there are a variety of downstream uses, and of course collection and evaluation sub-architectures.Now, imagine we're looking at a configuration management workflow. It shouldn't be a stretch to define configuration-management-specific roles and interfaces that participate in an architecture such as this one.A more detailed view of the above:+----------------------------------------------------------+| Orchestrator(s) |+-----------+----------------------------------------------+| +------------------------------+| | Posture Attribute Repository || +--------------^---------------+Perform |Collection || Collected Data| ^| |+-----------v------------------------------+---------------+| Integration Service |+----+------------------^-----------+------------------^---+| | | |v | v |Perform Collected Perform CollectedCollection Data Collection Data| ^ | ^| | | |+----v-----------------------+ +----|------------------|------+| Posture Collection Service | | | Endpoint | |+---^------------------------+ | +--v------------------+----+ || | | |Posture Collection Service| || v | +--------------------------+ |Events Queries +------------------------------+^ | (PCS resides on Endpoint)| |+---+-------------------v----+| Endpoint |+----------------------------+In the above, we show specific flows with specific information moving through the fabric between the various components that fulfill specific roles (note that one component can play more than one role, and that is by design). This is the level where, as dictated by the convention/semantics conveyed in the interface specification (i.e. an OpenDXL Ontology interface), the various data formats would be known.Hopefully this makes some sense. Essentially, we could choose to create three levels of diagram. One would be the security program view I conveyed by submitting this issue. The next level down could be the core or foundational roles we expect to support the various workflows demanded by the security program. The next level down could be program-/tool-specific workflow perspectives.Thoughts?—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOHPWUJWNL6CFO3GERO32CLRT7BZTANCNFSM4NMNYGRQ>. —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.  

[adammontville]

Hi @JasonKeirstead, I'm sorry I don't. I just copied directly from the SACM draft. If you want to create one in Draw.io, that'd be fine, or I can add it to my list to get done this week. Which of the two diagrams is the most interesting? Or, did you need for both?

[JasonKeirstead]

The detailed one is what I am thinking. I believe this could have OCA technologies overlayed into it.

Going to work on it now.

[JasonKeirstead]

@adammontville Please review at your leisure...

[adammontville]

Thanks @JasonKeirstead for creating that diagram. I think my initial line of thinking was that the SACM roles defined (Posture Collection Service, Posture Attribute Repository, etc.) could be on the same fabric as everything else, so I'm curious about the split. That said, I'm assuming that both the Security Data Fabric and the Integration Service in the diagram you created could be Open DXL.

I'm also less familiar with all that comes with the label "SOAR"... The Orchestrator in SACM is really a catchall for any orchestration that needs to take place for a supported workflow, and the collection is really all about state assessment and (eventually) behavioral observation.

[JasonKeirstead]

@adammontville I was trying to maintain the currennt arch. that SACM created and just overlay it. I didn't want to presume to re-do the SACM arch.

[JasonKeirstead]

@adammontville RE SOAR, this is, I think anyway, a bit of a different beast than the type of orchestration being disucssed in SACM. In SOAR the orchstreation is happening during the incident response life cycle. This is much more in the IACD - esque space. Next step maybe to take IACD arch. and also try to overlay it on this same diagram (which may replace the SOAR box)

[swood-tripwire]

@adammontville and @JasonKeirstead , Would you guys be game to do a walk through at our next working group meeting?

[adammontville]

@JasonKeirstead - Thanks for the additional explanation. When I see "SOAR" I tend to think of it as SOAR over an entire security program and not just incident response.

@swood-tripwire - I think a walk through would be good.

[sparrell]

I apologize because I haven't had time for OCA and so I'm terribly behind. Trying to follow this issue thread is hard, so I may be way off base. But I'm missing what the 'outputs' are. Assume the system works perfectly and all the interfaces work and all the boxes do their jobs, then what about this makes the organization more secure (ie reduces the risk to the business)? I think there has to be some 'output' somewhere where either something is presented to decision makes to act on, or the system automagically updates itself and changes something (eg updates a firewall rule, sends a file to malware detection, quarantines an infected endpoint, ...). In the IACD architecture it would 'acts'. Is that just the SOAR? And isn't SOAR connected to endpoints and security controls. I think we need to show something that shows an output we can tie to value (eg security controls changing)

[JasonKeirstead]

@sparrell The easiest way to think about this might be to say that almost every single thing in the IACD architecture would replace that one "SOAR" box. That would be step 3 here, to merge this all in.

[JasonKeirstead]

New attempt...

[MitchellJThomas]

Might I suggest applying a bit of the C4 model to this latest iteration.