sFractal Sweat Equity

2-June-2022 DC CAW

sFractal Sweat Equity

1. Introduction

Besides being stuckee on organizing CAW, sFractal intends to participate in the CAW with the “sweat equity” proposed in the following sections. This page is a sFractal-centric, PACE-centric view of the CAW plugfest.

2. Software/Application/Device -centric Contributions

2.1 BlinkyHaHa, BlinkyMaHa

Physical devices consisting of Raspberry Pi’s that implement the IoT “Hello World” and the OpenC2 “Hello World” over the HTTP/S and MQTT OpenC2 transfer specifications.

Software at:

Physical instantiations will be brought to plugfest. They will not be available remotely unless I get really creative with a 5G interface.

Status:

Hopefully will instantiate:

2.2 TwinklyHaHa, TwinklyMaHa

Digital twins for BlinkyHaHa, BlinkyMaHa. I.e. cloud servers that have webpage lights under OpenC2 control. Hopefully will instantiate:

Software at:

Intermittently instantiated at:

Status: Only minor work since last CAW, focused on making cloud instantiation easier and more like QuadBlockQuiz.

2.3 QuadBlockQuiz

QuadBlockQuiz is a tetrominoes-like game with quiz questions to get powerups to help with game. There are OpenC2 quiz questions. Plan is to update quiz with a PACE section of questions as well.

Hopefully by CAW, the webserver will be instantiated using OpenC2 commands and security command and control will be via OpenC2 commands (ie include the code already in the twinklies from last plugfest). Hopefully will instantiate:

Software at:

Instantiated at:

Status:

Help on anything appreciated, but especially on PACE and other quiz questions. Requires no programming experience, just markdown e.g. https://github.com/sFractal-Podii/quizquadaminos/blob/develop/qna/automation/001.md.

2.4 Ogres

sFractal will instantiate Open Graph Repository in Elixir for Sboms (OGRES) repo as a PACE system interfaced with Foad (see next section) and loaded with data from Oser (see next section).

Hopefully by CAW, the webserver will be instantiated using OpenC2 commands and security command and control will be via OpenC2 commands. Hopefully will instantiate:

Software at:

Instantiated at:

Status:

2.5 Foad

sFractal will instantiate Fake Orchestrator, Actuators, Decision-Makers (FOAD) repo to test Ogres (and hopefully other PACE systems).

2.6 Oser

The Ogres Sbom Examples Repo (OSER) will contain example SBOMs, VEXs, NVD CVE’s, and other “posture attributes” needed to evaluate/test Ogres and other PACE systems. Besides being an acronym, Oser is derived from “ose” and “oser”. Ose is the Latin suffix meaning “full of”, “abounding in”, “given to”, or “like”. So in this context, this repo is “abounding in” example data. Oser means “to dare”, as in “Do we dare to start populating this data?” :-)

Software at:

Instantiated at:

Status:

2.7 CAW website

This website will be used to coordinate and plan the workshop.

Software at:

Instantiated at:

Status:

2.8 DependencyTrack

In no one else does, then sFractal will instantiate a DependencyTrack website for use at the plugfest. Output from DependencyTrack is input to security posture so we will probably need a “lycan” for this DependencyTrack/Ogres-PCS interface.

2.9 Lycans

Hopefully, I’ll be using some of the existing lycans and make some new ones. “Lycan” is the OpenC2 word for software that “transforms” OpenC2 commands back and forth to proprietary API’s. Lycans are for OpenC2 what “shifters” are for STIX.

Ideally I’d add some simple lycans as proof-of-concept for PACE PCS- and/or PAR- and/or PES- OpenC2 interfaces to commercial SBOM products like:

These new lycans would sit between the bus and the “interfaces” box in P1 in the Pace picture in section 3.2. Probably outrunning my headlights unless vendors help with the lycans.

3. Which interfaces in which usecases

3.1 Comply to Connect Use cases

Comply to Connect

This is more relevant to the OpenC2 portion of the plugfest, but it does relate to PACE since PACE supplies the data for some of the decisions. Those are covered in the next section.

3.2 PACE Use Cases

PACE Arch

sFractal will set up Ogres to be any or all of P1, P2, P3, P8, P12 in the figure above. sFractal will set up Foad to simulate an orchestrator in the upper left of the figure above, as well as devices in the lower left of the figure above. BlinkyHaHa, BlinkyMaHa, TwinklyHaHa, TwinklyMaHa, QuadBlockQuiz, and CybersecurityAutomationWorkshop.com will be devices in the lower left of the figure above.

3.2.1 PCS Use Cases

Editor’s note: add more detail and on the 1,2,3,4 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#putting-an-sbom-into-pace with details on the various components, commands, and interfaces.

Editor’s note: add use case for SBOM on device and OpenC2 to get it

Editor’s note: add use case for MUD on device, referring to URL, and OpenC2 to get SBOM from URL

Editor’s note: add use case where orchestrator ‘just knows’ the URL of SBOM and OpenC2 gets SBOM from URL

Editor’s note: add use case where orchestrator tells PCS1 to get SBOM from PAR2 to put in PAR1; and OpenC2 gets SBOM from PAR2 in combo with other side use case from next section

3.2.2 PAR Use Cases

Editor’s note: add more detail and on the 3 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#putting-an-sbom-into-pace and on 1,2 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#getting-vex-information-from-pace and on 2,3,4 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#putting-an-sbom-into-pace with details on the various components, commands, and interfaces.

3.2.3 PES Use Cases

Editor’s note: add more detail and on the 1,2,3,4,5 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#evaluating-risk-from-a-new-cve with details on the various components, commands, and interfaces.

Editor’s note: Add use case where Orchestrator queries PES “is device_1234 affected by CVE_shellshock?” (ie an old already fixed one but we probably still don’t know answer). Sub-use cases with replies:

Editor’s note: Add variants of previous usecase with newer cve’s (solar wind, log4j) including lower risk score, including “yes exploitable”, …

3.2.4 Orchestrator Use Cases

Editor’s note: add more detail and on the 1,4 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#putting-an-sbom-into-pace and on 1,2 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#getting-vex-information-from-pace and on 1,5 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#putting-an-sbom-into-pace with details on the various components, commands, and interfaces.

3.2.5 EndPoint Use Cases

Editor’s note: add more detail and on the 2 in https://github.com/sparrell/PACE/tree/arch2/docs/Arch#putting-an-sbom-into-pace with details on the various components, commands, and interfaces.

Editor’s note: need to flesh out and add in new, or if appropriate earlier, section(s) wrt IIA01 and IIID01 in https://github.com/sparrell/PACE/blob/vex2/docs/Pace_Sbom_Vex_Flags_Prioritization/README.md#not_affected-flags from a PACE perspective.

3.2.6 Transformer Use Cases

Editor’s note: need to flesh out and add in new, or if appropriate earlier, section(s) wrt SBOM format difference/conversion/interaction use cases. E.g. what if SBOM S is in SPDX and SBOM C is in CycloneDx:

Return to Sweat Equity

return to Sweat Equity

Return to Agenda

return to Agenda

Return to Home

return to Home