SPECTRA — Mission elements in SPECTRA

Review 16-05-2025

[This comment that was originally linked to SV1 Annex A has a broader
scope, so I'll link it to CA]

• The scope of the stereotypes SPECTRA wants an end-user to apply is far broader than I think the RFC description lets on.
o And I understand why, external tools (BRM) needs to know system and mission decomposition to correctly measure mission and system risk.
o But I don’t think it’s practicable that we will be able to apply all these system and mission decomposition stereotypes in our models.
o I also believe SPECTRA should use or leverage other specifications or standards to determine mission and system decomposition as opposed to trying to create its own.
o I understand that there may not be other mature standards for some of these (besides OMG UAF) but I would rather work to fix that gap than approve this implementation that I feel is rushed and incomplete for modeling system and mission decomposition.
o I suggest for SPECTRA 1.0 you focus on the entities that are directly related to cyber concerns (data types, data flows, logic bearing components etc.).
o That may limit the ability of external tool to measure full mission risk – but I am not convince a cyber tool should be doing that anyways.
o In my mind, a cyber tool should determine cyber risk to logic bearing components and then bring those results back into our model to measure, compare, and collect against all the other risks we are developing and measuring for mission and system components.
o Once there are accompanying specifications or standards for mission and system decomp for SPECTRA to leverage, future SPECTRA releases can then connect with those specifications to gather that data.

NM: As an optional stereotypes, mission elements fit well into the rest of SPECTRA. Identifying mission elements together with other system elements allows understanding dependencies of mission tasks and identification the 5D type of risks (deny, disrupt, degrade, deceive, destroy) for missions and capabilities. Also this allows the same "machinery" to be used to interpret the "digital technical surface" of the system as (part of) its attack surface, and identify attack paths and prioritize them based on their mission impacts, which is the essence of Attack Path Analysis, and MRAP-C approaches. Not including mission elements as part of the assertions describing a cyber, or a cyber-physical system precludes these important analytics applications. Emphasis here is on mission elements being part of the same linked data set with other mandatory elements that enables analytics. Current fragmentation of standards makes this important analytics applications untenable.