The specifications from stixproject

In section 3.8 of the document, in the following sentence:

"Note that the STIX Common RelatedCampaignReferencesType class is used instead of the STIX Common RelatedCampaignType class."

RelatedCampaignReferenceType should be used.

Indicator Specification Doc: IndicatorType/Related_Packages not described as deprecated

IndicatorType/Related_Packages was deprecated in STIX 1.2, but this is not reflected in the document

Common Specification Doc - Typos in KillChainPhaseType section

section 3.4.1.1.1 should read:

A cyber kill chain is a phase-based model to describe the stages of an attack, and a cyber kill chain phase is an individual phase within a kill chain definition. The KillChainPhaseType class characterizes an individual phase within a kill chain.

Incident Specification Doc: JournalEntryType is a UML data type

JournalEntryType is described as a UML class in the document, but in the actual model it is a UML data type.

Create data marking processing specification

This specification will complement data model specification

Question: "Generalization Relations" for XSDDataTypes

I’ve picked up some artifacts ingesting the .emx files in my Visual Paradigm IDE. Before diving in, I was curious if anyone recognizes these (_0, _7yKF-…) off the top of your head as something that exists on your side and that should be there in the structures.

They are "Generalization Relations" for XSDDataTypes which seem out of sorts with the way everything else loads in nice "Human Readable" form.

For example:

_7yKF-CkGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/base64Binary?

Generalization  _7yKF-CkGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/base64Binary? CryptoBinary
Generalization  _7yKF-CkGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/base64Binary? DigestValueType
Generalization  _7yKF-CkGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/base64Binary? SignatureValueType

_7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString?

    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? PersonNameElementList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? OrganisationNameElementList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? PersonNameTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? OrganisationNameTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? SubDivisionTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? JointNameConnectorList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? NameLineTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? PartyNameIDTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? PersonNameUsageList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? PersonIDTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? OrganisationIDTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? OrganisationNameUsageList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? DependencyTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? RecordIDTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? AccountElementList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? BloodGroupList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? BirthInfoElementList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? CommunicationMediaTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? ContactNumberElementList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? DocumentElementList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? DocumentTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? ElectronicAddressIdentifierTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? FeatureTypeList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? LanguageSkillsList
    Generalization  _7yKF-ykGEdmDdasWev0kGA?XSDDataTypes/XSDDataTypes/normalizedString? MembershipElementList

Revisit "Relationship" descriptions in the property tables

An attempt has been made to describe relationship properties consistently across the documents. Some of the descriptions were enhanced in later specs - we should see if we need to use them in all of the docs.

check extension-related text for consistency

We should check the places where we discuss these extension (TTP, ET, Indicator, Common). They may not be particularly consistent. For example, in Indicator, the diagram for TestMechanismType shows the extensions differently than in TTP (attributes shown in latter, but not former).

Produce XSD Binding Spec

A step-by-step process on how to convert the UML model into the STIX XSD.

Campaign Specification Doc: Various misspellings and typos

Exploit Target Sepecification doc: Various mispellings and typos

Write up Campaign <=> Threat Actor bi-directional relationship

Describe in spec why a TTP should use only one of its properties at a time

The properties of TTP should have been implemented by a "choice", instead of "sequence".

Complete UML Model for STIX

Finalize design of how to model Mutually Exclusive XSD Choice in UML
(indicator:CompositeIndicatorExpression)
Need better name for "RestrictedString" - the UML data type we
introduced for properties that used to be XSD attributes of type xs:string
(maybe NoEmbeddedQuotesString)
AssetTypeType needs to inherit from ControlledVocab, but if the type is
AffectedAssetType.Type is AssetTypeType, then you can't have an uncontrolled
vocab in that property.
NonPublicDataCompromisedType - same as 3.
Some <> left in extensions
id/idref can't both be specified.
In incident/ExternalImpactAssessment ModelType it is invalid to have
neither model_name or model_reference

Indicator Specification Doc: Various mispellings and typos

Incident Specification Doc: Various mispellings and typos

Determine if and how to include Suggested Practices

We have a lot of suggested practices for STIX constructs. It has been decided
that they are inappropriate in the spec docs. How should we include them?
Just refer to the wiki page? Format wiki page and other suggestions as a
separate doc??

Update Copyright & Trademark info of STIX 1.2.1 specs to account for DHS contributions

The Copyright & Trademark info of the STIX 1.2.1 specs needs to be updated to account for negotiated IPR considerations of the DHS contributions.

Add the following text to each specification document after the standard OASIS copyright and disclaimers:

STIX™, TAXII™, AND CybOX™ (STANDARD OR STANDARDS) AND THEIR COMPONENT PARTS ARE PROVIDED “AS IS” WITHOUT ANY WARRANTY OF ANY KIND, EITHER EXPRESSED, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY THAT THESE STANDARDS OR ANY OF THEIR COMPONENT PARTS WILL CONFORM TO SPECIFICATIONS, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR FREEDOM FROM INFRINGEMENT, ANY WARRANTY THAT THE STANDARDS OR THEIR COMPONENT PARTS WILL BE ERROR FREE, OR ANY WARRANTY THAT THE DOCUMENTATION, IF PROVIDED, WILL CONFORM TO THE STANDARDS OR THEIR COMPONENT PARTS. IN NO EVENT SHALL THE UNITED STATES GOVERNMENT OR ITS CONTRACTORS OR SUBCONTRACTORS BE LIABLE FOR ANY DAMAGES, INCLUDING, BUT NOT LIMITED TO, DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES, ARISING OUT OF, RESULTING FROM, OR IN ANY WAY CONNECTED WITH THESE STANDARDS OR THEIR COMPONENT PARTS OR ANY PROVIDED DOCUMENTATION, WHETHER OR NOT BASED UPON WARRANTY, CONTRACT, TORT, OR OTHERWISE, WHETHER OR NOT INJURY WAS SUSTAINED BY PERSONS OR PROPERTY OR OTHERWISE, AND WHETHER OR NOT LOSS WAS SUSTAINED FROM, OR AROSE OUT OF THE RESULTS OF, OR USE OF, THE STANDARDS, THEIR COMPONENT PARTS, AND ANY PROVIDED DOCUMENTATION. THE UNITED STATES GOVERNMENT DISCLAIMS ALL WARRANTIES AND LIABILITIES REGARDING THE STANDARDS OR THEIR COMPONENT PARTS ATTRIBUTABLE TO ANY THIRD PARTY, IF PRESENT IN THE STANDARDS OR THEIR COMPONENT PARTS AND DISTRIBUTES IT OR THEM “AS IS.”

In addition insert trademark designation at the following locations:

Insert it in each first occurrence of the strings (STIX, TAXII, CybOX).
Insert it in each occurrence of the string in any title, caption or subheading.

Need clarifying documentation around CIQ

The schema documentation for CIQ can be misleading for how we use it. For example, "Nationalities" is claimed to be only valid for a "Person" in schema documentation (and CIQ is usually specific about the Party/Organization/Person distinction) but we use it for anything. I am not sure where this would go (FAQ?).

TTP Specification Doc: TTPType/Related_Packages not described as deprecated

TTPType/Related_Packages was deprecated in STIX 1.2, but this is not reflected in the document

Report Specification doc: Various mispellings and typos

Produce Vocab spec doc

TTP Specification Doc: Various mispellings and typos

Complete UML Model for MAEC

Normalize property naming across specifications and UML

When the XSD was transformed to UML, we made a conscious decision to not change the names of properties in any way - including case. Since XSD attribute names were lower case, they remained lower case in the UML model. We should consider using the same format for all names going forward.

Review NON-Common Descriptions spreadsheet

Tabs for core, common, data markings and vocab need to be reviewed

Exploit Target Specification doc - ExploitTargetType/Related_Packages not described as deprecated

ExploitTargetType/Related_Packages was deprecated in STIX 1.2, but this is not reflected in the document

Create versioning processing specification

As a follow-on, include a reference implementation

Complete UML Model for CyBOX

Document TTP/Kill_Chains vs. TTP/Kill_Chain_Phases vs. TTPs/Kill_Chains

The spec should differentiate what they mean and when to use one or the other.

Core Specification Doc: STIXType/timestamp not described as deprecated

STIXType/timestamp was deprecated in STIX 1.2, but this is not reflected in the document

Common Specification Doc - CampaignBaseClass description missing text

All base class descriptions have a similar sentence in their description, except CampaignBaseClass. This should be added:

The one case where the class SHOULD NOT be extended is when the CampaignBaseType class is used as a reference via its idref property.

IndicatorTypeVocab needs to be improved

There is a discussion on cti-users and cti-stix about improving the IndicatorTypeVocab.

I believe that having a vocab is a useful thing. But I believe the existing vocab needs to be improved.

First off, type information, like e-mail, ip, file hash, domain, etc. should be removed. You should/must be able to get this information from the Observable that is part of the Indicator.

For one, there is no vocab to describe a malicious observiable, say network packet, stream, or other activity. Though if the e-mail type is removed from Malicious E-mail, and it just became Malicious (Observable), then we would have something.

Removing type information would reduce the IndicatorTypeVocab down to:
Compromised
Malicious
Watchlist
C2
Anonymization
Exfiltration

The first three are interesting, Compromised means that this Observable indicates that you ARE compromised. The Malicious means that you WILL be compromised by this Observable and Watchlist means that you MAY get compromised by this Observable.

Arguably, C2 should fall under Compromised, but as it probably requires further investigation to figure out the original compromised host, I'm fine leaving this as it's own separate type.

Create indicator evaluation specification

The evaluation specification will complement the data model specification.

Include content on how to use parameter observables

Produce Overview spec doc

Produce Incident spec doc

Threat Actor Sepecification doc: Various mispellings and typos

Common Specification Doc - Various misspelling and typos

Bulleted items in Section 2 of the specs should be consistent

The level of detail of the bulleted items in Section 2 of the component specifications varies. In the Core and Overview document, we have a minimal amount of information - no "capturing such information as..." sentence. However, in the component documents, some of the bullets have this additional information and some do not - they should be consistent.

stixproject / specifications Goto Github PK

specifications's People

Contributors

Stargazers

Watchers

Forkers

specifications's Issues

Recommend Projects

Recommend Topics

Recommend Org