Architecutre diagram viewpoint

[adammontville]

I apologize it has taken me a while to submit this. I think I understand what the architecture diagram is driving to. I wonder if we could take a different viewpoint, or at least a singular one. We have the communication fabric at the center, and a variety of notional boxes connected by that fabric. These boxes seem to be labeled from an operational perspective or a security program perspective or from a product class perspective.

Would it make sense to look at this from the security program perspective and start hanging the major program areas we believe exist for a given security program? Because I am with CIS, I'll mention some of the more prominent program areas the CIS Controls talks about: Asset Management, Configuration Management, Vulnerability Management, Log Management, Incident Management, Systems Development Management, Training and Awareness, Penetration Testing, Data Management, and so on.

Then, for each of those program areas we could create a program-specific view of the architecture. For example, Configuration Management will certainly leverage some common components from Asset Management (a CMDB, for example), but also have other components involved for policy definition/content repositories, collectors, evaluators, and the like.

For reference, the CIS Controls alludes to or explicitly mentions around 40 distinct tools, which is a lot to try to condense into a single diagram.

Taking this perspective may additionally serve to be an indicator of how well OCA is covering the various aspects of a generic security program.

Thoughts?

[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:notifications@github.com] Sent: Friday, May 29, 2020 7:35 AM To: opencybersecurityalliance/documentation documentation@noreply.github.com Cc: Stephen Wood swood@tripwire.com; Mention mention@noreply.github.com Subject: Re: [opencybersecurityalliance/documentation] Architecutre diagram viewpoint (#2)

[EXTERNAL]

Thanks @swood-tripwirehttps://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 GitHubhttps://github.com/opencybersecurityalliance/documentation/issues/2#issuecomment-636007803, or unsubscribehttps://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 notifications@github.comTo: opencybersecurityalliance/documentation documentation@noreply.github.comCc: Subscribed subscribed@noreply.github.comSubject: [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:notifications@github.com]Sent: Friday, May 29, 2020 7:35 AMTo: opencybersecurityalliance/documentation documentation@noreply.github.comCc: Stephen Wood swood@tripwire.com; Mention mention@noreply.github.comSubject: Re: [opencybersecurityalliance/documentation] Architecutre diagram viewpoint (#2)[EXTERNAL]Thanks @swood-tripwirehttps://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 GitHubhttps://github.com/opencybersecurityalliance/documentation/issues/2#issuecomment-636007803, or unsubscribehttps://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.