opencybersecurityalliance/documentation

This repository contains Enablement Documentation (STIX Shifter), Workgroup documents and materials (Endpoint), Working documents and output from the "Architecture Working Group", Architecture workgroup meeting minutes and recordings

documentation's Issues

Update readme

Update readme on master branch to include branching strategy (since all the info seems to be in branches) so users know where to see where we are, and how to supply input

Need to define what this repo is for

Create C4 diagrams for Threat Intelligence Sharing System

We have context, container and component diagrams for SCAP; we need the same set for Threat Intelligence. We need expertise in threat intelligence systems to help us here.

Posture Collection System

For this diagram, https://github.com/opencybersecurityalliance/documentation/blob/dee00b859dd2d1255fa22c05a0817420f6902518/Architecture%20Documents/SACM-context.pdf

Would the endpoints be a component that would be depicted with an arrow to the posture collection system? I would like to see what ties to the posture collection system so we have a end-to-end view.

Need to evolve the architecture terminology document (iterative approach)

An initial terminology document is posted in our Github repository. The initial entries have been populated as we progress the C4 diagrams. Please review and add relevant terminology to this document.

broken links on root README

Found the target of these broken links in "documentation/Architecture Documents/oldfiles" moved 9mo ago by warrenrjwc

I don't see what files replace them clearly so I'm just filing this issue as FYI

Fix broken images links in readme

I introduced (boo hiss) broken links in PR #14. I'll get those cleaned up.

Create System Landscape Diagram (C4) to capture high level OCA architecture

Provide a C4 diagram (System Landscape) to replace our current high level draft diagrams of the OCA architecture. Our current architecture has the following issues:

• Need to add people and their persona
• Need to add the security devices and controls (ex firewalls, IPS, etc)
• Need to be consistent on representing products/security functions/capabilities

This repo need a license file

OASIS Open rules (section 15.2) require each repo to have a license. This one somehow slipped thru a crack. Given the broad nature of contents (marketing, architecture, zero trust, indicators, TSC, ...), I think should be discussed at PGB to decide which one (and to meet the letter of the rules). Ie I could just make a PR and add one - but I think PGB should do the actual pick of which one.

How is the security system secured from attackers?

Who or what is securing the security system?
What happens when malware is introduced into this system? If it's connected to everything that seems like a great vector to create a lot of damage.

Idea: Borrow context and components from NIST's Zero Trust Architecture. Say assume an identity provider, user/role based encryption, message authentication codes and a risk posture system that allows for self assessment to occur.

Architecutre diagram viewpoint

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?

Suggestion: Diagrams and Documents should include an Acronym Table

Suggestion: Diagrams and Documents should include an Acronym Table.

Although we are expanding the range of thought, much of the jargon around these topics might seem like "newspeak" to those we we are trying to engage/expose. All Acronyms in a given diagram or document should have the related term called out. Any new terms should have a brief explanation.

Architecture: Security Automation Workflow Enumeration

Provide an example of workflows from an existing project (CIS 7.1 Controls)

Architecture: Investigate C4 Model for Diagrams

Assignment - look into C4 model tool to use to draw our architecture diagrams and help document the interactions between components. Update current draft drawing to SCAP V2 and eliminate product references (creating a functional architecture diagram). Create an initial terminology document.

Align SCAP with OpenDXL Ontology.

Align SCAP with OpenDXL Ontology. There is not a current ontology for posture information. This is a key area for SCAP. We need to start working on OpenDXL Ontology and align with SCAP’s current architecture and formats.

Evolve our current use cases to drive our architecture definitions

Starting with our current Use case 1, continue to evolve our current diagrams and document to cover the use case. This will focus and scope our progress with the end goal of demonstrating the ICA architecture and its approach and value. Our goal is go get this use case completed by June 2021.

Do usecase document in markdown instead of pdf to allow PR's

The usecase document is stored as a pdf (https://github.com/opencybersecurityalliance/documentation/blob/master/Architecture%20Documents/Use%20Cases%20for%20Open%20Cybersecurity%20Alliance%20v1.pdf). I would prefer documents, when possible, be stored in a form that comments and changes could be input with github tools. The typical way for text in github is to use markdown (eg for README.md)

Manager component - unclear what it is

I am unclear on the manager component listed in the latest diagrams https://github.com/opencybersecurityalliance/documentation/blob/dee00b859dd2d1255fa22c05a0817420f6902518/Architecture%20Documents/SACM-container.pdf

It would seem the threat intelligence system and the configuration policy management system would directly query the repository. Can you elaborate on the management component to clarify this?