opencybersecurityalliance / documentation Goto Github PK

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

HTML 100.00%

architecture oca-objectives

documentation's Introduction

Open Cybersecurity Alliance documentation

What is in this repo:

Project Documentation (STIX Shifter, OpenDXL Ontology)
Workgroup documents and materials (Endpoint)
Working documents and output from the "Architecture Working Group"
Architecture workgroup meeting minutes and recordings
Project Governing Board (PGB) meeting minutes
Technical Steering Committee meeting minutes
Marketing work group minutes
Materials for the IOB Working Group

Architecture Working Group

The OCA Architecture Working Group organizes and discusses its activities in a public mailing list as well as the #architecture-wg channel on the OCA Slack workspace. Click here to join us on Slack and Click here to subscribe to the list.

The branch we are using is under master, called doc-architecture. Here is where you will find the latest working documents from the workgroup. Issues are opened to track work underway. Please add your comments under these issues. We will merge changes into the master once the architecture work group has discussed and agreed to the proposed changes. Our project board shows the open actions items and issues that are currently being discussed.

Architectural Images

The OCA Architectural diagram

This architectural diagram follows the C4 model for a description of Contexts, Containers and Components.

Other orientations

Architecture 6 diagram

SACM OCA diagram

SACM OCA IACD diagram

documentation's People

Contributors

Stargazers

Watchers

Forkers

vshanks-cydarm warrenrjwc elkulback sparrell laurie-tyz loyno-opencybersecurityalliance roseann-guttierrez mozammalhossain ekmixon andrewbeard hecg119 sumodgeorge ian-feathers hlinh1988 charlesfrick gtrunsec

documentation's Issues

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.

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

Fix broken images links in readme

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

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.

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

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?

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.

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.

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.

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.

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?

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.

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)