OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fwd: Call for Comment: proposed Charter for Heimdall Data Format (HDF) TC


Greetings CTI Members, Â

I recently joined the OASIS staff as theÂEcosystems Development Manager. I'm excited to be working with all of you!Â

Last Friday, Chet sent the draft charter (forwarded) below. It describes a new OASIS TC that allows for a standard format for exchanging normalized security data between cybersecurity tools - Heimdall Data Format ( HDF).Â

Note that the charter's "Related work" sectionÂcites CTI. If you are interested in being part of the HDF TC or you have questions about theÂdraft charter, please contact the proposer,ÂAaron LippoldÂ(alippold@mitre.org)Âof MITRE. Since you are already an OASIS TC member, there is no additional cost to participating in HDF.

Best,
Jasmine Mbadugha

---------- Forwarded message ---------
From: Chet Ensign <chet.ensign@oasis-open.org>
Date: Fri, Dec 2, 2022 at 5:39 PM
Subject: Call for Comment: proposed Charter for Heimdall Data Format (HDF) TC
To: <project-announce@lists.oasis-open.org>, Members <members@lists.oasis-open.org>, OASIS Charter Discuss List <oasis-charter-discuss@lists.oasis-open.org>
Cc: <Mike.Fraser@sophos.com>, <Andy.Thomas@sophos.com>, Aaron L Lippold <alippold@mitre.org>, Brett Kreider <kkreider@mitre.org>, Eugene J Aronne <earonne@mitre.org>, Jasmine Mbadugha <jasmine.mbadugha@oasis-open.org>, Carol Geyer <carol.geyer@oasis-open.org>


To OASIS Members:

A draft TC charter has been submitted to establish the Heimdall Data Format (HDF) TC. In accordance with the OASIS TC Process Policy section 2.2: (https://www.oasis-open.org/policies-guidelines/tc-process#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 23:59 GMT on 15 December 2023.

OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending an email to: oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail.

Comments received will be reviewed by the proposers and a log of the comments and their resolution will be posted to oasis-charter-discuss mailing list before the telephone call with the convener.

A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend no more than four days after the comment period closes. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar.

We encourage member comment and ask that you note the name of the proposed TC (HDF) in the subject line of your email message. Comments received will be reviewed by the proposers and a log of the comments and their resolution will be posted to oasis-charter-discuss mailing list before the telephone call with the convener.

If you wish to be listed as a co-proposer in the Call for Participation, please contact the convener Aaron Lippold, MITRE, alippold@mitre.org. For representatives of OASIS organizational members, a statement of support from their Primary Representative will be required.

--- TC charter ---

Section 1: TC Charter

(1)(a) TC Name

The Heimdall Data Format (HDF) Technical Committee (TC)

(1)(b) Statement of Purpose

The purpose of the TC is to develop a standard format for exchanging normalized security data between cybersecurity tools. This data exchange specification will be called the Heimdall Data Format (HDF).

In this context:

* 'Standardization' is the process of defining data elements in a consistent and contextualized manner.
* 'Normalization' is the process for mapping a format's data elements into another format's data elements.

Security tools typically generate data in unique formats that require multiple dashboards and utilities to process. This leads to a time-consuming process for completing security assessments, data in disparate locations and inconsistent semantics of a data element between formats. Furthermore, many security tools do not provide context to relevant compliance standards for comparison across security tools.

HDF will provide a common data exchange format that:
* Enables the consistent integration, aggregation, and analysis of security data from all available sources
* Preserves data integrity with original source data
* Maximizes interoperability and data sharing
* Facilitates the transformation and transport of data between security/management processes or technologies
* Allows for the mapping and enrichment of security data to relevant compliance standards (GDPR, NIST SP 800-53, PCI-DSS, etc.)

The TC will update HDF as industry needs evolve.

Business Benefits

A standard vendor-agnostic data format supports cybersecurity product interoperability without the need for customized integrations.

Participating stakeholders and adaptors should benefit from this TC:

* For Commercial and Vendor Cybersecurity Partners, HDF defines a standardized, interoperable target format that vendor tools can consume across their customer base consistently and that is easily managed within the product lifecycle.
* For the Open Source Community, HDF enables easy integration with commercial solutions without the need for direct partnerships.
* For Government Agencies, HDF can streamline business processes by having a standard, open source, machine-readable format for all security data.
* For Academia, HDF offers a structured way to communicate and enhance research findings throughout the security community.
* For Corporate and Federal CISOs/CIOs, HDF can increase visibility across the enterprise by taking advantage of normalized security data in a standard format that supports risk information interoperability from a broad range of inputs to support security risk decision-making.
* For Security Engineers, HDF can reduce resource requirements for multiple security data types by standardizing formatting across disparate security tools.
* For Risk Managers, HDF can improve decision making by using a standardized format to facilitate automation, standardize communication requirements, and inform risk-based analysis.
* For DevSecOps/Software Engineers, HDF can streamline CI/CD processes by leveraging a standardized format to collate/aggregate normalized security data to support automated and continuous security processes.

(1)(c) Scope

The scope of work of the TC is to produce a specification that defines the HDF format, as well as supporting documentation and open source content. The TC will draft specifications, lexicons, or other documents to allow exchange of security data in a standardized manner. The TC will leverage pre-existing standards to the greatest extent practical.

The TC will base its initial efforts on HDF specifications generated by The MITRE Corporation as part of the MITRE Security Automation Framework (MITRE SAF (c)). MITRE SAF (c) will contribute the open source specifications and related documentation developed for HDF to the HDF TC.

Additionally, the TC will reference example implementations from MITRE SAF (c) tooling for accessing and visualizing the data. It is expected that other organizations and interested individuals in the larger community will also develop implementations and tooling.

(1)(d) Deliverables

* An OASIS specification that defines the Heimdall Data Format (HDF). (~6 months from start date)

* Other materials as necessary to ease adoption of the specification, such as: educational materials, supporting documentation, and open source content.

The Heimdall Data Format will be an evolving standard, and consequently this TC will continue to make changes and produce materials as required to adapt the format to any new security data considerations.

(1)(e) IPR Mode

This TC will operate under the Non-Assertion IPR mode as defined in Section 10.3 of the OASIS IPR Policy document.

(1)(f) Audience

* Corporate and Federal CISOs/CSOs
* Security data vendors
* Federal contractors
* National standards agencies and institutes, e.g., US National Institute of Standards and Technology (NIST)

(1)(g) Language

* English

(Optional References for Section 1)

https://saf.mitre.org (MITRE SAF(c) Home page)
https://github.com/mitre/heimdall2/tree/master/libs/inspecjs (example _javascript_ implementation of the HDF standard)

Section 2: Additional Information

(2)(a) Identification of Similar Work

The TC will consider the relationship of HDF to the following standards:

* Asset Reporting Format (ARF) and Extensible Configuration Checklist Description Format (XCCDF) focuses on common configuration enumerations (CCE)

* Static Analysis Results Interchange Format (SARIF) describes common vulnerabilities and exposures (CVE) and common weakness enumerations (CWE)

* Open Command & Control (OpenC2) is a standardized language for the command and control of technologies that provide or support cyber defenses

* Posture Attribute Collection & Evaluation (PACE) is a project for understanding security posture which could benefit from HDF as an input

* Structured Threat Information _expression_ (STIX) is a language and serialization format used to exchange cyber threat intelligence

* National Information Exchange Model (NIEM) is a standard for creating specific automated information exchanges within and across organizations and disciplines

Each of these specifications addresses a subset of the data exchange challenge. HDF provides a way to preserve data from the aforementioned formats and allows for expanding their usability as described in this charter. The HDF TC will consider how HDF should interoperate with these standards, leveraging the strengths and specific use cases for each.


(2)(b) First TC Meeting

The first meeting will be held Wednesday, 01 February, 2023 at 15:00 utc/4:00 pm cet/10:00 am est/7:00 am pst. MITRE will host the meeting.

(2)(c) Ongoing Meeting Schedule

* Monthly

(2)(d) TC Proposers

* Mike Fraser, Sophos, Mike.Fraser@Sophos.com
* Andy Thomas, Sophos, Andy.Thomas@sophos.com
* Aaron Lippold, MITRE, alippold@mitre.org
* Brett Kreider, MITRE, kkreider@mitre.org
* Eugene Aronne, MITRE, earonne@mitre.org Â
Â
(2)(e) Primary Representatives' Support

* I, Joe Levy, as OASIS Primary Representative for Sophos, confirm our support for the HDF TC proposed charter and approve participation by our participant named in the charter as a co-proposer.

* As OASIS primary representative for MITRE, I, Raj Rajagopal, confirm our support for the HDF proposed Charter and endorse our participants listed above as named co-proposers.

(2)(f) TC Convener

* Aaron Lippold (MITRE)

(2)(g) Anticipated Contributions

* Finalizing the draft specification
* Eliciting additional requirements
* Proposing reference implementation tooling and utilities

(2)(i) FAQ Document

* MITRE Security Automation Framework (https://saf.mitre.org/#/normalize)

(2)(j) Work Product Titles and Acronyms

* HDF: Heimdall Data Format

--

ChetÂEnsign

Chief Technical Community Steward

OASIS Open

ÂÂÂ
+1 201-341-1393
chet.ensign@oasis-open.org
www.oasis-open.org


--

JasmineÂMbadugha

Ecosystem Development Manager

OASIS Open

ÂÂÂ
+1.929.582.1094
jasmine.mbadugha@oasis-open.org
www.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]