System Profile for Effective Cyber Threat-based Risk Assessments Avatar
  1. OMG Specification

System Profile for Effective Cyber Threat-based Risk Assessments — Open Issues

  • Acronym: SPECTRA
  • Issues Count: 67
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SPECTRA-67 Suggested illustrations for SV1 SPECTRA 1.0a1 open
SPECTRA-2 SV1 Annex A must be completed SPECTRA 1.0a1 open
SPECTRA-66 Mission elements in SPECTRA SPECTRA 1.0a1 open
SPECTRA-64 Make stereotype name more distinctive SPECTRA 1.0a1 open
SPECTRA-65 Improve Figure 2,3 SPECTRA 1.0a1 open
SPECTRA-63 Split SV1 stereotypes into mandatory and optional SPECTRA 1.0a1 open
SPECTRA-62 Use of classifiers and abstract base classes is recommended SPECTRA 1.0a1 open
SPECTRA-61 Additional information section needs clarification SPECTRA 1.0a1 open
SPECTRA-60 SPECTRA objectives need clarification SPECTRA 1.0a1 open
SPECTRA-59 Clarify the use of word "language" in definition of SPECTRA SPECTRA 1.0a1 open
SPECTRA-58 SV1 Core Assertions Compliance Point needs clarification SPECTRA 1.0a1 open
SPECTRA-57 Boolean proporties should not have "is" in the name SPECTRA 1.0a1 open
SPECTRA-56 CSV rules need clarification SPECTRA 1.0a1 open
SPECTRA-55 Missing definitions in Context Package SPECTRA 1.0a1 open
SPECTRA-54 Mitigation Package AllocatedControl needs clarification SPECTRA 1.0a1 open
SPECTRA-53 Mitigation Package SCTM class should be renamed SPECTRA 1.0a1 open
SPECTRA-52 Physical characteristics need clarification SPECTRA 1.0a1 open
SPECTRA-51 Cyber characteristics need clarification SPECTRA 1.0a1 open
SPECTRA-50 Domain characteristics need clarification SPECTRA 1.0a1 open
SPECTRA-49 Mission package needs clarification SPECTRA 1.0a1 open
SPECTRA-48 Behavior package needs clarifications SPECTRA 1.0a1 open
SPECTRA-47 Agent analytics needs clarification SPECTRA 1.0a1 open
SPECTRA-46 Agent Category enumeration needs clarification SPECTRA 1.0a1 open
SPECTRA-45 Access package needs clarification SPECTRA 1.0a1 open
SPECTRA-44 Artifacts package Storage Media needs more literals SPECTRA 1.0a1 open
SPECTRA-43 Artifacts package Network elements need more literals SPECTRA 1.0a1 open
SPECTRA-42 Artifacts package Software enum needs clarifications SPECTRA 1.0a1 open
SPECTRA-41 Artifacts Package Computing Elements enumeration needs rework SPECTRA 1.0a1 open
SPECTRA-40 Artifacts Package virtualization area needs clarification SPECTRA 1.0a1 open
SPECTRA-39 Artifacts package needs clarifications (general) SPECTRA 1.0a1 open
SPECTRA-38 Kernel Functional Thread needs clarification SPECTRA 1.0a1 open
SPECTRA-37 Capability definition could be improved SPECTRA 1.0a1 open
SPECTRA-36 Kernel ImpactfulElement needs clarification SPECTRA 1.0a1 open
SPECTRA-35 Kernel DataType needs clarifications SPECTRA 1.0a1 open
SPECTRA-34 Kernel CarrierInterface needs rework SPECTRA 1.0a1 open
SPECTRA-33 Kernel Exchange needs clarifications SPECTRA 1.0a1 open
SPECTRA-32 Kernel ChannelCategoryEnum is ambiguous SPECTRA 1.0a1 open
SPECTRA-31 Kernel Package 'Node' name may interfere with many existing profiles SPECTRA 1.0a1 open
SPECTRA-30 In Kernel Package elements redefine name and purpose SPECTRA 1.0a1 open
SPECTRA-29 Rename GlobalControlElement to GlobalMitigationElement SPECTRA 1.0a1 open
SPECTRA-28 Need stronger definitions for COnfigurationElement, MitigationElement, SystemElement SPECTRA 1.0a1 open
SPECTRA-27 INTRO Definitions of Node and Tangible SPECTRA 1.0a1 open
SPECTRA-26 INTRO Definitions of Risk SPECTRA 1.0a1 open
SPECTRA-25 INTRO General issues with definitions SPECTRA 1.0a1 open
SPECTRA-24 INTRO add exact version of NIST-800-53 reference SPECTRA 1.0a1 open
SPECTRA-23 INTRO Revise description of SPECTRA as a "filter" SPECTRA 1.0a1 open
SPECTRA-22 INTRO Alignment with RAAML SPECTRA 1.0a1 open
SPECTRA-21 INTRO Need more detail regarding alignment with UAF SPECTRA 1.0a1 open
SPECTRA-20 INTRO Digital technical surface SPECTRA 1.0a1 open
SPECTRA-19 INTRO Identify and revise unproven claims SPECTRA 1.0a1 open
SPECTRA-18 SV1 multiplicities must be made explicit SPECTRA 1.0a1 open
SPECTRA-17 SV1 profile must avoid string typed attributes whenever possible SPECTRA 1.0a1 open
SPECTRA-16 SV1 Remaining cases of "over specification" must be removed SPECTRA 1.0a1 open
SPECTRA-15 SV1 Cameo profile must have documentation for all tags SPECTRA 1.0a1 open
SPECTRA-14 SV1 metaclasses must be more specific SPECTRA 1.0a1 open
SPECTRA-13 SV1 profile must not use generic "Model" as the name of the top element Model SPECTRA 1.0a1 open
SPECTRA-12 SV1 Cameo profile must include all definitions SPECTRA 1.0a1 open
SPECTRA-11 SV2 syntax errors in the .sysml file reported by SysIDE SPECTRA 1.0a1 open
SPECTRA-10 INTRO must emphasize resilience and survivability SPECTRA 1.0a1 open
SPECTRA-9 SV2 references must be finalized SPECTRA 1.0a1 open
SPECTRA-8 SV2 Annex A must be completed SPECTRA 1.0a1 open
SPECTRA-7 SV2 inventory file SPECTRA 1.0a1 open
SPECTRA-6 References must be finalized SPECTRA 1.0a1 open
SPECTRA-5 SV1 profile naming conventions must be finalized SPECTRA 1.0a1 open
SPECTRA-4 INTRO must finalize common definitions SPECTRA 1.0a1 open
SPECTRA-3 SV1 Annex B must be aligned with CA SPECTRA 1.0a1 open
SPECTRA-1 SV1 inventory file designations SPECTRA 1.0a1 open

Issues Descriptions

Suggested illustrations for SV1

  • Key: SPECTRA-67
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    [Specific illustrations suggested for Annex A or elsewhere in SV1 spec]
    o One critical thing I feel is missing is demonstrating who SPECTRA expects data types and data flows to be modeled (along with channels).
    o There are no example documentation or diagrams currently for how to “mark” activity diagrams and sequence diagrams.
    o I would like to see some of those to properly assess how SPECTRA expects those to work with its stereotype implementation.
    o An example and better explanation for SPECTRA “domains” implementation should also be added as I did not have a clear understanding of their feasibility based on the specification alone.
    o It doesnt really explain why they create proprietary stereotypes that already seem to be fulfilled by the tool itself. Example “Subsystem”.
    o Lacked any information in general about the Stereotypes themselves.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:40 GMT
  • Updated: Mon, 21 Jul 2025 15:40 GMT

SV1 Annex A must be completed

  • Key: SPECTRA-2
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v1 Preliminary AB Reviews 03-03-2025
    The example in Annex A was helpful with respect to understanding how this would be applied, and I’m sure will be appreciated by your user community. There are a number of empty clauses towards the end of the annex, however. An RFC is supposed to be complete as implemented in various tools.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 13:48 GMT
  • Updated: Mon, 21 Jul 2025 15:37 GMT

Mission elements in SPECTRA

  • Key: SPECTRA-66
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:36 GMT
  • Updated: Mon, 21 Jul 2025 15:36 GMT

Make stereotype name more distinctive

  • Key: SPECTRA-64
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    there are a lot of stereotypes with very generic names in SPECTRA that will likely conflict with other profiles. SPECTRA will be one of hundreds of profiles applied to some models so having distinctive stereotype names would be beneficial to avoid confusion.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:18 GMT
  • Updated: Mon, 21 Jul 2025 15:24 GMT

Improve Figure 2,3

  • Key: SPECTRA-65
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    [INTRO] Page 14, Figure 2, Page 15 Figure 3
    • The paint or snippet tool arrows applied to these figures appear rough and are harder to consume than they might be if a different drawing package tool was utilized.

    NM: these are the figures "Digital Technical Surface of a system" and "Artifacts with supply chain detail"

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:21 GMT
  • Updated: Mon, 21 Jul 2025 15:21 GMT

Split SV1 stereotypes into mandatory and optional

  • Key: SPECTRA-63
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Related to section Additional Information

    From our perspective this [SPECTRA4SV1] would be considered a large profile.
    o For our large programs we must petition and negotiate with systems engineering for each separate stereotype that we want added to the system model.
    o Each engineering function has dozens, or hundreds, of stereotypes contained in various profiles that they all want added to do their analysis.
    o For most large programs, systems engineering is resistant to adding any stereotypes beyond what is mandatory.
    o I recommend splitting SPECTRA profile into the mandatory and optional stereotype packages and profiles so end-users can be more selective on what to bring into their model.
    o As stated above, I also recommend refocusing SPECTRA so that the main use case is properly modeling cybersecurity needs in a system model. That way it can be the main bulk of the stereotypes we need to include in a model from a cyber perspective. If it is limited to just being an export translator profile, then we will likely need to have very similar profiles of our own that properly model cybersecurity needs from a system security engineering perspective. It would be better if SPECTRA could do that with a side effect of being able to export.

    NM: section 6 "Additional Information: How to read this specification" already mentioned "essential" and "optional" stereotypes. I like the suggested approach to emphasize the "mandatory" nature of some elements, in the direction of "properly modelling cybersecurity needs in a system model".

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:17 GMT
  • Updated: Mon, 21 Jul 2025 15:17 GMT

Use of classifiers and abstract base classes is recommended

  • Key: SPECTRA-62
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Some of our programs, especially on the DoD side, are moving away from using stereotypes (or allowing the use of them) and instead focusing on using classifiers and having abstract base classes that other entities extend to gain access to properties. On some DoD programs SPECTRA will be a non-starter as stereotypes are not used w/ SysML 1.0 models for those programs.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:09 GMT
  • Updated: Mon, 21 Jul 2025 15:09 GMT

Additional information section needs clarification

  • Key: SPECTRA-61
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Additional Information section.
    You should spell out numbers below ten and in some cases one hundred.

    NM: this comment is rather unclear.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:06 GMT
  • Updated: Mon, 21 Jul 2025 15:06 GMT

SPECTRA objectives need clarification

  • Key: SPECTRA-60
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    “SPECTRA’s objective is to provide a standard compliance reference for acquisition contracts soliciting models for various assessments, as well as tools and services for performing such assessments automatically” –
    o I would much rather SPECTRA be used to define the required elements for cybersecurity analysis within a model and the use cases mentioned here be secondary.
    o By focusing SPECTRA almost exclusively on what can be taken out of a model for analysis I believe you are only scratching the surface of what capabilities could be brought to bear for a model and what a framework like SPECTRA could do.
    o I also believe that because SPECTRA is solely interested in extracting data from a model it may promote poor model-based system security engineering practices.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:02 GMT
  • Updated: Mon, 21 Jul 2025 15:02 GMT

Clarify the use of word "language" in definition of SPECTRA

  • Key: SPECTRA-59
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    “SPECTRA is a language for describing cyber and cyber-physical systems for the purposes of risk assessments, cybersecurity assessments and vulnerability assessments” – SPECTRA is not a language.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 15:00 GMT
  • Updated: Mon, 21 Jul 2025 15:00 GMT

SV1 Core Assertions Compliance Point needs clarification

  • Key: SPECTRA-58
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    “Software that conforms to the SPECTRA Consumer compliance point shall ingest SysML XMI documents annotated with stereotypes defined in this SPECTRA specification.”- for some of our larger models the system definition might be spread across multiple different models (XMI files) so one single XMI file might not be compliant to the specification but the accumulation of multiple XMIs files the define system model would.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:59 GMT
  • Updated: Mon, 21 Jul 2025 14:59 GMT

Boolean proporties should not have "is" in the name

  • Key: SPECTRA-57
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    • Properties (column titles) that are Boolean values should not have “is” in the name. These seem patterned like the common Java getter/setter function style but should not be used to model data.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:51 GMT
  • Updated: Mon, 21 Jul 2025 14:51 GMT

CSV rules need clarification

  • Key: SPECTRA-56
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    CSV rules in section How to read this specification need clarification.
    • “Boolean value true can be represented as true, True, yes, y, Y” – recommend adding “T” to the acceptable value list to represent true.
    • “Boolean value false can be represented as false, False, no, n, N or blank” –
    o Recommend adding “F” to the acceptable value list to represent false.
    o I would prefer a blank value is invalid as opposed to read as “false”. In some cases, this may be problematic.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:50 GMT
  • Updated: Mon, 21 Jul 2025 14:50 GMT

Missing definitions in Context Package

  • Key: SPECTRA-55
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    SPECTRA Context package
    • The properties in this package are missing descriptions in this document.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:49 GMT
  • Updated: Mon, 21 Jul 2025 14:49 GMT

Mitigation Package AllocatedControl needs clarification

  • Key: SPECTRA-54
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Allocated Control -
    o I don’t agree that an AllocatedControl is linked to only a single MitigableElement. Controls are broad statements of functionality for mitigation and often not a specific implementation. A control might be used in many different MitigableElements.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:48 GMT
  • Updated: Mon, 21 Jul 2025 14:48 GMT

Mitigation Package SCTM class should be renamed

  • Key: SPECTRA-53
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    SCTM –
    o I would suggest not using an acronym for an element name. As a property name is still not great, but acceptable.
    o I also suggest not using a specific DoD deliverable as an element in a general schema. For example. we don’t call it an “SCTM” typically when dealing with commercial aviation.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:47 GMT
  • Updated: Mon, 21 Jul 2025 14:47 GMT

Physical characteristics need clarification

  • Key: SPECTRA-52
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Enumeration Literals for Physical Characteristics -
    o Missing definition for “Electronic” enumeration literal.
    o Missing definition for “Power” enumeration literal.
    o It seems Mechanical and Kinetic are redundant terms here, I would remove one of them to avoid confusion.
    o Missing definition for “Magnetic” enumeration literal.
    o The definition for “Electromagnetic” should specifically mention that it excludes Infrared and when EM waves travel over optic cable (Optical).,
    o Missing definition for “Spacial” enumeration literal. Would also rename to “Spatial” to avoid confusion.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:46 GMT
  • Updated: Mon, 21 Jul 2025 14:46 GMT

Cyber characteristics need clarification

  • Key: SPECTRA-51
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    • Enumeration Literals for Cyber Characteristics –
    o Digital – I would remove the term “automated” word from this definition and define “digital information”.
    o Missing a Definition for Analog
    o Cloud & DataCenter – I don’t understand the distinction here. Cloud seems like a superfluous enumeration literal here and should be removed.
    o Human – “subject to social engineering attacks” seems like a strange addition to this definition. Humans are subject to lots of different attack types including blackmail and coercion, to name a few. Calling out just one attack type is odd.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:45 GMT
  • Updated: Mon, 21 Jul 2025 14:45 GMT

Domain characteristics need clarification

  • Key: SPECTRA-50
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Characteristics Package.
    Enumeration Literals for Domain –
    o Application – I suggest changing this to “Mission Domain” as, from what I understand, it specifies elements of the system that support the Functions that Mission Tasks depend on.
    o Security – Copy and paste error in the Definition of Security. “Marking an element as belonging to the application domain…” I am assuming it should read “belonging to the security domain…”
    o I suggest adding a “Safety Domain” at the minimum.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:44 GMT
  • Updated: Mon, 21 Jul 2025 14:44 GMT

Mission package needs clarification

  • Key: SPECTRA-49
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    General – I would rather SPECTRA just rely on the Mission Engineering work OUSD is already doing rather than recreate it here. Seems some connection points to the Mission Engineering work could have been defined as opposed to creating more stereotypes for the same data. Most DoD programs now will have at least two profiles with Mission elements in them and will need to model a Mission at least twice, once to make SPECTRA work and once to meet requirements defined by OUSD Mission Engineering handbook.

    Mission –
    o I suggest Mission should also be linked to a human (or organization) who is the stakeholder and sets parameters for acceptable risk and CIA objectives.
    o Mission should have some sort of priority. Not all missions are alike and shouldn’t be treated alike.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:42 GMT
  • Updated: Mon, 21 Jul 2025 14:42 GMT

Behavior package needs clarifications

  • Key: SPECTRA-48
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Function –
    o It is not clear to me if this Function is the same as the Function depicted with a relationship to Agent in the previous section. That relationship to Agent is not shown here so we are led to believe it is a different function. If so, they should be named differently to avoid this confusion.
    o Curious why the choice to have Function only write to a single DataStore? In some cases, for redundancy, two data stores (or more) may have the same data written to them. I think that multiplicity should be re-examined.
    o isFInal – typo in “Final”. Should be “Final”

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:40 GMT
  • Updated: Mon, 21 Jul 2025 14:40 GMT

Agent analytics needs clarification

  • Key: SPECTRA-47
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Agent Analytics –
    o I think some of these multiplicities should be examined. Why model an agent if it has no function, mission, Thread, or Capability?
    o I also am confused by the “all_data” relationship between Agent and DataType. That is not explained at all.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:39 GMT
  • Updated: Mon, 21 Jul 2025 14:39 GMT

Agent Category enumeration needs clarification

  • Key: SPECTRA-46
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Agent Category Enumeration –
    o “Hazard” is not a type of agent. Hazards are situations that may result in loss. This needs to be rectified because it is not at all consistent with how our peers in safety engineering think about hazards and we need to have a consistent terminology with safety. This would be a good opportunity to leverage what RAAML has for Hazard.
    o I would suggest the enumeration is missing “stakeholder”, “owner”, and perhaps “developer” at least. All are agents who, through functions they perform in defining or designing the system, introduce cyber risk.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:38 GMT
  • Updated: Mon, 21 Jul 2025 14:38 GMT

Access package needs clarification

  • Key: SPECTRA-45
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    • Accesses – is this logical (connection) access or physical access? A maintainer may only be able to log into a single device on a platform but can physically access nearly the entire platform. Clarity here in the description would be helpful to distinguish.

  • Reported: SPECTRA 1.0a1 — Mon, 21 Jul 2025 14:37 GMT
  • Updated: Mon, 21 Jul 2025 14:37 GMT

Artifacts package Storage Media needs more literals

  • Key: SPECTRA-44
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    • Storage Media – Though the definition discusses it, there are no separate enumerations for primary, secondary, tertiary (etc.) storage. I think it would be useful to distinguish between an HDD or a USB thumb-drive when determining the security of where data is stored so I expected more values in their enumeration than just the single one.

  • Reported: SPECTRA 1.0a1 — Wed, 16 Jul 2025 00:27 GMT
  • Updated: Mon, 21 Jul 2025 14:32 GMT

Artifacts package Network elements need more literals

  • Key: SPECTRA-43
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    • Network Elements – I would suggest adding “Layer 3 Switch”, “Encryptor”, and “Access Point”

  • Reported: SPECTRA 1.0a1 — Wed, 16 Jul 2025 00:26 GMT
  • Updated: Wed, 16 Jul 2025 00:26 GMT

Artifacts package Software enum needs clarifications

  • Key: SPECTRA-42
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025
    • Software – this enumeration is missing some important options. Would suggest at least Driver, Firmware, Server, and Web Server but there are likely more.

  • Reported: SPECTRA 1.0a1 — Wed, 16 Jul 2025 00:25 GMT
  • Updated: Wed, 16 Jul 2025 00:25 GMT

Artifacts Package Computing Elements enumeration needs rework

  • Key: SPECTRA-41
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    • Computing Elements – This is not a consistent list of elements that makes sense. It varies from an LRU or component (DSP) to a broad term for almost anything (Hardware), to software (Firmware), to a specific hardware type (Mobile Device). This does not pass the test for a good enumeration in my opinion. If nothing else, a sizable number of other types of computing element types should be added to enable proper analysis for tools. Everything from “laptop” to “driver” is missing given the broad nature of the current elements on the list. This list is also missing Operational Technology (OT) and Internet of Things (IoT) type devices that I believe should be covered.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 22:08 GMT
  • Updated: Tue, 15 Jul 2025 22:08 GMT

Artifacts Package virtualization area needs clarification

  • Key: SPECTRA-40
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    • is Virtualized – need to provide a lot more details on what this means. There are lots of different types of “virtualization” available and without more clarity on what is expected to be “true” versus “false” it is unclear how to use this property.
    • hostedIn – “stuff” is hosted in more than just Cloud Infrastructure as the description states. The Cloud is just someone else’s server after all. It could be hosted on a server, a virtual server, a mobile device, a laptop etc. Also, unless there are most restrictions than shown, it looks like a valid model would have a “Cloudinfrastructure” hostedIn a “Firmware” hostedIn a “Library” hostedIn a “Dsp” etc. One side effect of mushing all these OSI layer elements together.
    • Cloud Infrastructure – having an enumeration with a single value makes no sense modeling wise. The enumeration value is also the same as the name. I would think at least different sorts of cloud infrastructure would be modeled here. If the goal is to model virtualization options, then it should also include more than cloud virtualization such as processor emulation and local virtualization. The use case for this enumeration is not clear for modeling tools.

    NM: This area is very important as there are many regulatory controls for cybersecurity that specifically address virtualized environments. Understanding virtualization in the model of a given system of interest is therefore critical to the objectives of risk assessment and has profound implications to the shape of the attack surface.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 22:07 GMT
  • Updated: Tue, 15 Jul 2025 22:07 GMT

Artifacts package needs clarifications (general)

  • Key: SPECTRA-39
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    SPECTRA Artifacts package
    • Same note about “is” in Boolean properties names.
    • Combining so many different types of devices, across the OSI Layers, into one element will lead to a lot of confusion and errors. It is not akin to how the systems are designed or typically modeled. Recommend a much more thorough model to be developed that properly outlines the different layers and the elements types.

    NM: I've grouped the section into several issues with related areas. The one here seems to be a general comment, unless it applies to virtualization area.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 22:04 GMT
  • Updated: Tue, 15 Jul 2025 22:04 GMT

Kernel Functional Thread needs clarification

  • Key: SPECTRA-38
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Functional Thread
    o Integer – should specific whether the integer is expected to start at 0 or 1.
    o Booleans should not have “is” in the name of them. That is a programming convention for accessor functions. It is not good modeling practice.
    o “Specifies whether the flow involves access” – does this mean whether access control is used for the flow or whether the flow itself is part of enabling access control? It is not clear.
     Same note for authentication and encryption
    o RAAML already has a specification for defining a series of sequential events (Situation and Scenario) that should be extended here instead of recreated.
    o How are concurrent flows or unordered flows modeled? Data traveling on a bus or using something like UDP typically has not guaranteed delivery order, so the system is created where delivery order is not necessary.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:59 GMT
  • Updated: Tue, 15 Jul 2025 21:59 GMT

Capability definition could be improved

  • Key: SPECTRA-37
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025
    Capability
    o I think the OUSD Mission Engineering scheme and handbook does a much better job describing system capability, mission, and functionality in a model than this specification. It should be adopted here instead of recreating a new version.

    NM: current alignment is with UAF, which is an available OMG specification, in particular to the Mission Profile.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:58 GMT
  • Updated: Tue, 15 Jul 2025 21:58 GMT

Kernel ImpactfulElement needs clarification

  • Key: SPECTRA-36
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025
    Impactful Element
    o Typically, there are three main objectives, CIA, I am not sure where “privacy” and “safety” came from. These are both outcomes from maintaining CIA objectives and should not be listed as their own objectives. For example, “Safety” is not something measured by an “ImpactLevel”.
    o If this is meant to describe the system stakeholder desires for the system, beyond the mission, I do not think it does a good enough job. If we are moving beyond the typical “CIA” context then there are dozens of outcomes here that a system stakeholder could care about: performance, stability, resiliency, cost etc. Just like with safety I do not think this is a good way to measure stakeholder “wants” here.

    NM: I would like to consider moving in the direction of capturing the key concerns that a system stakeholder could care about, as enumerated here. This is used to frame the risk claims appropriately, where the risk claims must be precisely aligned with the concerns of the stakeholders.
    NM: there is also a related suggestion to use the 5D for the Capabilities and Mission, such a Deny, Degrade, Destroy, Deceive, Disrupt, Deter. While they map to CIA, they add distinct flavour that addresses concerns for cyber and especially cyber-physical systems

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:55 GMT
  • Updated: Tue, 15 Jul 2025 21:55 GMT

Kernel DataType needs clarifications

  • Key: SPECTRA-35
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    DataType
    o The definition says DataType is only for data between replaceable units, why would it not also be used for data passing in and out of the system through the boundary?
    o classification – is this the maximum expected classification level for the data? The minimum? Or is it classification of the data type itself or just the data that datatype represents? I would suggest that this field be optional as it is only applicable to military systems, and this is a public international RFC.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:48 GMT
  • Updated: Tue, 15 Jul 2025 21:48 GMT

Kernel CarrierInterface needs rework

  • Key: SPECTRA-34
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Carrier Interface
    o I don’t understand the strange mix of layers here in this data element. It makes for a very confusing model. I suggest this is split up into different elements for clarity’s sake.
    o Semantics:
     I don’t understand why SPECTRA is dependent on the tools to define these enumerations but also provides a list here in the RFC that the tools should enforce. I recommend either a proper specification of an enumeration or a totally free String field. The strange half measure will not work well across multiple tool vendors.
     Transport Protocol: Not every message follows one of these two transport protocols. This isn’t even a complete list of the typical internet protocol suite. It also doesn’t consider systems that don’t use internet protocol suite transport protocols.
     Network protocols: this is not a list of network protocols per the referenced OSI layer. If this list is intended to be something else, then it should be renamed. If not, it will lead to confusion. It is also missing some needed values such as ARNIC 629 and EFABus.
     Network interface: This is a strange list of values that don’t match the “network interface” term in my opinion. “RF for SATCOM” is an entire suite of protocols. “Ethernet” is the common name for a cable type. “1553” is a bus protocol and “Wi-Fi” is, again, an entire suite of RF protocols. This field needs to be completely reworked and is part of the problem of mushing a bunch of OSI layers together. It’s unworkable as it is now.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:47 GMT
  • Updated: Tue, 15 Jul 2025 21:47 GMT

Kernel Exchange needs clarifications

  • Key: SPECTRA-33
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Exchange –
    o Definition: it is common in some networks, especially of the hub architecture, to have a single producer create a data element that multiple consumers consume. Or to have multiple producers create a data item that a single consumer consumes. The definition (and model) of Exchange says it’s a single producer to single consumer. I believe this will limit its usability in many systems.
    o Semantics: I do not believe this semantically assertion made here is true. There are sometimes where the message is encrypted along the channel path without knowledge or involvement of the direct producer or consumer. There are intermediate “nodes” between a producer and consumer that are often transparent to the message sender or recipient.

    NM: With regards to the definition, this must be aligned with SysML and AAR. The current practice (AAR/CSV and SysML) for the situation of multiple consumers is to duplicate exchanges. Depending on the kind of attack, usually only a specific exchange is impacted. Regarding encryption: in a thread/dataflow that traverses multiple channel segments, there are multiple exchanges involved. If encryption is transparent to the end nodes, then the initial and final exchanges are not encrypted, but at least one exchange involved in the thread is. Exchange is supported by some capability of both the sender and the receiver, e.g. protocol support. In case of encryption, there is key management and exchange. Understanding exactly which exchanges are encrypted and which are not is important to understand bypass, and data leaks.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:45 GMT
  • Updated: Tue, 15 Jul 2025 21:45 GMT

Kernel ChannelCategoryEnum is ambiguous

  • Key: SPECTRA-32
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    ChannelCategoryEnum –
    o I do not agree with the enumeration literal options for this enumeration.
    o There are different types of networks and one of those types is a bus network.
    o “Bus” and “Network” are not separate things.
    o I believe “Network” is not the correct term here if you are talking about a hub and spoke type communications architecture as commonly implemented with routers.

    NM: the intention was to keep bus as a very specific choice for e.g. ARINC 429 or MIL STD 1553. Link is a dedicated point to point connection, such as an antenna cable. In this case another literal is needed for more common types like Ethernet. Note also that there is specific CarrierInterface associated with a Channel to specify protocols and their significance for cyber security (e.g. whether a protocol susceptible to propagate an IUEI).

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:34 GMT
  • Updated: Tue, 15 Jul 2025 21:34 GMT

Kernel Package 'Node' name may interfere with many existing profiles

  • Key: SPECTRA-31
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    Node –
    o Recommend a different, more distinct, name for this element.
    o Our system models typically have dozens if not hundreds of profiles applied to them and Node is a very common term between them.
    o This leads to confusion and, in some cases, errors even when the full element name may be different.
    o All the elements in this package have generic and easily conflicting names but node is the most egregious.
    o I think going with the suggested “Processing Element” would have been better in this case.

    NM: Note, that ProcessingElement is used as an application trait in Traits package together with Controller, Transducer, Sensor, Actuator. However since Node is an abstract element in SPECTRA, it should not cause any issues and should not be difficult to rename.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:27 GMT
  • Updated: Tue, 15 Jul 2025 21:27 GMT

In Kernel Package elements redefine name and purpose

  • Key: SPECTRA-30
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    General –
    o Why does each element redefine “name” and “purpose”?
    o Having those properties in a shared parent element would be better modeling.

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:22 GMT
  • Updated: Tue, 15 Jul 2025 21:22 GMT

Rename GlobalControlElement to GlobalMitigationElement

  • Key: SPECTRA-29
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2025

    GlobalControlElement – I prefer how in MitigationElement “control” is not in the name of the element. It should be renamed “GlobalMitigationElement.”

    NM: CommonPackage and GlobalControlPackage

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:19 GMT
  • Updated: Tue, 15 Jul 2025 21:19 GMT

Need stronger definitions for COnfigurationElement, MitigationElement, SystemElement

  • Key: SPECTRA-28
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Review 16-05-2024
    ConfigurationElement, MitigationElement, SystemElement:
    For each of these the description does not actually describe this element, it just makes a broad statement about a group of elements. Should be made more clearly if this is being used to define this element

  • Reported: SPECTRA 1.0a1 — Tue, 15 Jul 2025 21:17 GMT
  • Updated: Tue, 15 Jul 2025 21:17 GMT

INTRO Definitions of Node and Tangible

  • Key: SPECTRA-27
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA Review 16-05-2025
    “Node” & “Tangible”–
    o I don’t believe “tangible’ versus “intangible” are the correct adjectives to use for physical versus virtual “nodes”. Not based on the definition of tangible given next.
    o Just because a node is virtual does not mean it’s impossible to “understand or realize”. I believe virtual nodes are still “discernable,” “facts,” and “real” otherwise we would not be concerned with them for a cyber risk assessment.
    o I suggest a different differentiating adjective used in the definition of “Node” or replace the definition of “Tangible” because right now there is a contradiction.

    Node –
    o Recommend a different, more distinct, name for this element.
    o Our system models typically have dozens if not hundreds of profiles applied to them and Node is a very common term between them.
    o This leads to confusion and, in some cases, errors even when the full element name may be different.
    o All the elements in this package have generic and easily conflicting names but node is the most egregious.
    o I think going with the suggested “Processing Element” would have been better in this case.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:53 GMT
  • Updated: Mon, 2 Jun 2025 15:41 GMT

INTRO Definitions of Risk

  • Key: SPECTRA-26
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA review 16-05-2025
    • “Risk” -
    o This definition does not match any standard definition of risk I know of - I suggest using a standard definition, such as from one of the referenced NIST documents or from the OMG RAAML specification, for such a common term to avoid confusion.
    o This is one place where I believe SPECTRA should leverage RAAML. RAAML is a broader language for modeling risk and risk mitigation. SPECTRA could add a specific “cyber risk” and “cyber risk mitigation” perspective on top of that.
    o Every other definition of risk includes a combination of impact and likelihood. This definition only mentioned impact. Risk without likelihood is just impact.
    o This definition also more correctly describes the term “cyber risk” not “risk” which is a much broader concept than just cybersecurity.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:51 GMT
  • Updated: Mon, 2 Jun 2025 15:41 GMT

INTRO General issues with definitions

  • Key: SPECTRA-25
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA review 16-05-2025
    • Inconsistent capitalization for definitions.
    • Some of these definitions look like they were taken from elsewhere without proper attribution

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:50 GMT
  • Updated: Mon, 2 Jun 2025 15:41 GMT

INTRO add exact version of NIST-800-53 reference

  • Key: SPECTRA-24
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA review 16-05-2025
    I suggest listing the version of the references. For example, “800-53” has five different major revisions with major differences.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:47 GMT
  • Updated: Mon, 2 Jun 2025 15:41 GMT

INTRO Revise description of SPECTRA as a "filter"

  • Key: SPECTRA-23
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA review 16-05-2025
    Section "scope"
    • “Cybersecurity implies a filter for the level of technical detail, compared to other disciplines involved in the system lifecycle” – this statement does not make sense to me. Each discipline looks at the system definition with a different filter. It’s not clear to me how or why cybersecurity is different here.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:45 GMT
  • Updated: Mon, 2 Jun 2025 15:41 GMT

INTRO Alignment with RAAML

  • Key: SPECTRA-22
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA review 16-05-2025
    • The first sentence about RAAML is copy and pasted from the RAAML profile document without attribution and includes a reference to “this document” which appears to mean the RAAML profile and not the SPECTRA CA RFC document.
    • The section does not mention the upcoming RAAML 2.0 specification that specifically includes security analysis nor the common use of RAAML 1.X to support security analysis.
    • The claims that RAAML is not aligned w/ SPECTRA in scope is also unfounded.
    o Though RAAML was initially a safety specification, safety and security share common concerns for how to understand and model scenarios that result in measurable risk to a system that needs to be mitigated.
    o RAAML has representations for attack trees, scenarios, risks, and risk mitigations that are all applicable to cybersecurity.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:44 GMT
  • Updated: Mon, 2 Jun 2025 15:41 GMT

INTRO Need more detail regarding alignment with UAF

  • Key: SPECTRA-21
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA review 16-05-2025
    For the UAF section. The formatting seems different than the rest of the document. Was this copy and pasted from another source? If so, it needs attribution.
    This section also described UAF at a high-level but does not actually describe how SPECTRA and UAF interact as the section title suggests it would.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:43 GMT
  • Updated: Mon, 2 Jun 2025 15:41 GMT

INTRO Digital technical surface

  • Key: SPECTRA-20
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA review 16-05-2025
    I don’t think we need a new term for “Digital technical surface”. There are plenty of existing terms we should look to reuse.

    “Digital Information Pathway” & “Digital Technical Surface” –
    o Personal preference here, but I quite dislike these terms and feel them unnecessary.
    o I feel there are existing terms already used in the domain that would fit here, and we don’t need more buzzwords in a domain already jam-packed with them.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:41 GMT
  • Updated: Mon, 2 Jun 2025 15:41 GMT

INTRO Identify and revise unproven claims

  • Key: SPECTRA-19
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA review 16-05-2025
    I feel like a lot of the front matter in the preface makes unproven claims and assumptions about SPECTRA and its usefulness for cyber physical systems modeling and its integration w/ other standards.
    Unproven claims and lack of real world case studies/examples that demonstrate real world successes.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:40 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

SV1 multiplicities must be made explicit

  • Key: SPECTRA-18
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA feedback 30-04-2025
    In SPECTRA v1 profile multiplicities must be made explicit.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:01 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

SV1 profile must avoid string typed attributes whenever possible

  • Key: SPECTRA-17
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA feedback 30-04-2025
    String-typed attributes are used in SPECTRA SV1 in lieu of relationships which are often missing in existing SysML models, but are deemed necessary as core assertions for cyber. Examples of this are tags key, assembly key and group key in Information Pathway stereotype. While SPECTRA uses these tags to accommodate existing models and minimize the cost of adding SPECTRA annotations so that core assertions can be extracted, the practice of using matching string types tags may impede automatic testing of the elements and relationships.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 15:00 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

SV1 Remaining cases of "over specification" must be removed

  • Key: SPECTRA-16
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA feedback 30-04-2025
    Acting as a filter/annotation language for existing SysML models, SPECTRA must avoid "over specification" ("over tagging") which describes a situation where the information required by the Core Assertions is already available in the SysML model and should not be required to be entered as tags to SPECTRA stereotypes.
    Specific example is tag "supplier name" in Supply Chain Element. It may be beneficial to focus on the "supplies" relation that is already defined for stereotype Supplier. While the supplier name was introduced to accommodate existing models where there is no explicit supplier as a model element, the reviewer argues that the modeller must be forced to create a Supplier element, and use the supplies relation.
    This is related to overtaking, since the name of the supplier is in the Supplier element.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:53 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

SV1 Cameo profile must have documentation for all tags

  • Key: SPECTRA-15
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA feedback 30-04-2025
    Cameo machine-readable profile must include documentation (definition) for all tags.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:40 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

SV1 metaclasses must be more specific

  • Key: SPECTRA-14
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA feedback 30-04-2025
    Metaclasses in the v1 profile must be as specific as possible. In several cases, metaclasses are Element. This must be tightened. Metaclasses must be aligned with the SPECTRA inference rules.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:37 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

SV1 profile must not use generic "Model" as the name of the top element Model

  • Key: SPECTRA-13
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA v1 feedback 30-04-2025
    Cameo machine-readable profile must not use generic name "Model" as the name of the top element Model. Rename to something like "SPECTRAv1".

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:34 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

SV1 Cameo profile must include all definitions

  • Key: SPECTRA-12
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA feedback 30-04-2025
    Cameo machine-readable profile must include all relevant definitions from the specification.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:27 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

SV2 syntax errors in the .sysml file reported by SysIDE

  • Key: SPECTRA-11
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    24-03-2025
    Tried to load the.sysml file into SysIDE and it reported several errors (missing semicolons, elements defined multiple times, part defs with type annotations, parts typed as String, and similar). Corrected .sysml file is available, with fixed syntax errors and added TODO comments for cases in which the original intention was not clear.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:22 GMT
  • Updated: Mon, 2 Jun 2025 15:40 GMT

INTRO must emphasize resilience and survivability

  • Key: SPECTRA-10
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Comments on OMG SPECTRA for SySML v1 RFC 2nd reading sysa-24-11-01
    March 13, 2025
    Summary
    The standard is aimed at cyber risk assessment with respect to three architectural quality attributes: Confidentiality, Integrity, Availability.
    These 3 attributes are foundational to system cyber security.
    However, per latest DoD policy, there are additional cyber-related attributes for mission-critical and safety-critical systems that need to be addressed by the standard. These are cyber resiliency and survivability.
    Details
    As noted on pages 15 and 16:
    “To be precise, a Cyber system (CS) involves computing devices, networks, and programs to process digital information. A Cyber-Physical System (CPS) is a cyber system that integrates physical processes with computational algorithms and networked sensors to monitor and control physical processes in real time. A cyber-physical system is a collection of computing devices communicating with one another and interacting with the physical world via sensors and actuators in a feedback loop.”
    “Cyber Security is protection of digital information, as well as the integrity of the infrastructure housing and transmitting digital information. More specifically, cyber security includes the body of technologies, processes, practices and response and mitigation measures designed to protect networks, computers, programs and data from attack, damage or unauthorized access so as to ensure confidentiality, integrity and availability.”

    The OMG SPECTRA standard is aimed at cyber risk assessment with respect to three architectural quality attributes: Confidentiality, Integrity, Availability (CIA).
    These 3 attributes, CIA, are foundational to system cyber security.
    For mission- and safety-critical systems, this is a necessary but not sufficient condition. The DoD has instituted additional system attributes as follows.
    Cyber Resiliency
    NIST SP 800-160 Vol 2, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach defines cyber resiliency as follows (line 442, page 6):
    “Cyber resiliency is defined as “the ability to anticipate, withstand, recover from, and adapt to
    adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by
    cyber resources.” Systems with this property are characterized by security
    measures that are “built in” as a foundational part of the architecture and design. Moreover,
    these systems can withstand cyber attacks, faults, and failures and can continue to operate even
    in a degraded or debilitated state, carrying out mission-essential functions, and ensuring that
    the other aspects of trustworthiness (i.e., safety and information security) are preserved.”

    NIST 800-160 Vol 2, Appendix D describes cyber resiliency constructs. SPECTRA needs to address these.

    System Survivability
    DOD INSTRUCTION 5000.83 , TECHNOLOGY AND PROGRAM PROTECTION TO MAINTAIN TECHNOLOGICAL ADVANTAGE has codified the cyber resiliency attribute as follows (page 4):
    “Programs will employ system security engineering methods and practices, including cybersecurity, cyber resilience, and cyber survivability in design, test, manufacture, and sustainment. Such methods and practices will ensure that systems function as intended, mitigating risks associated with known and exploitable vulnerabilities to provide a level of assurance commensurate with technology, program, system, and mission objectives.”
    The policy also establishes System Survivability as a Key Performance Parameter (pages 15 & 16):
    “Design for Security and Cyber Resiliency.
    To design, develop, test, and acquire systems that can successfully operate in the face of threats, to include cyber threats, as well as in denied environments, lead systems engineers will:
    (c) Ensure that key performance parameters and attributes establish:
    1. System survivability and sustainment measures.”

    OMG SPECTRA needs to embrace this and address this KPP.

    Recommendations
    Cyber threats are evolving constantly and at a fast pace. The US Government, especially the Department of Defense, has led the charge in ensuring that the systems procured by the DoD can operate successfully in a contested cyber environment. They must continue to perform mission-essential functions by gracefully degrading rather than crash and burn. They must also continue to operate safely, even in the face of cyber attacks by nation-state adversaries.
    DoD has codified these needs as policy. NIST has published very helpful guides to implement cyber resiliency and survivability attributes into the DoD products.
    Cyber risk assessment standards, such as OMG SPECTRA, must also evolve to embrace these architectural attributes such as those in NIST SP 800-160 in general, and specifically, Appendix D, and be able to model risks of resilient and survivable systems.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:16 GMT
  • Updated: Mon, 2 Jun 2025 15:39 GMT

SV2 references must be finalized

  • Key: SPECTRA-9
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v2 Preliminary AB Reviews 03-03-2025
    A number of normative clauses appear to be less complete than what you have in the SysML v1 version

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:06 GMT
  • Updated: Mon, 2 Jun 2025 15:39 GMT

SV2 Annex A must be completed

  • Key: SPECTRA-8
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v2 Preliminary AB Reviews 03-03-2025
    The example in Annex A, in comparison with the example in the SysML v1 RFC, is virtually nonexistent aside from having paragraph numbers

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:04 GMT
  • Updated: Mon, 2 Jun 2025 15:39 GMT

SV2 inventory file

  • Key: SPECTRA-7
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v2 Preliminary AB Reviews 03-03-2025
    the text file (KerML?) should be categorized as a machine-readable file.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:01 GMT
  • Updated: Mon, 2 Jun 2025 15:39 GMT

References must be finalized

  • Key: SPECTRA-6
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v1 Preliminary AB Reviews 03-03-2025
    References are incomplete as well – you need to point to the exact versions of the specifications that are relevant. And, all of the specifications, OMG and otherwise, that this specification relates to should be listed, even if non-normative. The discussion of references and how they overlap with SPECTRA is really great – please make sure that gets into the main specification and that they are all referenced with links appropriately.
    NM: this applies primarily to volume 1. Must finalize the essential references in other volumes.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 14:00 GMT
  • Updated: Mon, 2 Jun 2025 15:39 GMT

SV1 profile naming conventions must be finalized

  • Key: SPECTRA-5
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v1 Preliminary AB Reviews 03-03-2025
    I have more detailed issues with naming conventions and other things in the model itself, but if these terms are what the community is using and are derived from the USAF template, then ok.
    NM: the reviewer to provide more detail

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 13:57 GMT
  • Updated: Mon, 2 Jun 2025 15:39 GMT

INTRO must finalize common definitions

  • Key: SPECTRA-4
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v1 Preliminary AB Reviews 03-03-2025
    Definitions are light in some cases, and the text runs together in other places – hopefully that will be addressed in finalization.
    NM: definitions have been consolidated in the volume 1; more detail to be provided by the reviewer.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 13:55 GMT
  • Updated: Mon, 2 Jun 2025 15:36 GMT

SV1 Annex B must be aligned with CA

  • Key: SPECTRA-3
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v1 Preliminary AB Reviews 03-03-2025
    Annex B includes details of the core assertions metamodel, that will require maintenance in sync with the core assertions standard – does that make sense? Is the intent to eliminate that annex and refer to the core assertions specification in the body of the profile specification once that specification is available? Shouldn’t they all reference one another (or at least, the two profiles should reference the core assertions metamodel that they depend on?).

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 13:49 GMT
  • Updated: Mon, 2 Jun 2025 15:36 GMT

SV1 inventory file designations

  • Key: SPECTRA-1
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    SPECTRA for SysML v1 Preliminary AB Reviews 03-03-2025:
    Issues with the SysML v1 profile inventory: the XMI file should be categorized as a machine-readable file, and the cameo .mdzip file should be ancillary.

  • Reported: SPECTRA 1.0a1 — Mon, 26 May 2025 13:44 GMT
  • Updated: Mon, 2 Jun 2025 14:01 GMT