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: Re: [cti] Re: [EXT] [cti] Motion for Open Repository for STIX Enhancement Proposals

I have to say I agree with Brett and share the same objection. The TC has not come to any decision on what any kind of a STIX enhancement process looks like, let alone whether it would even use Github at all.

Whether or not certain entities are or are not using a privately-agreed-upon process is beside the point. I would suggest that said work could continue in any Github repo, perhaps one hosted by that community.

Jason Keirstead
Lead Architect - IBM Security Cloud

"Things may come to those who wait, but only the things left by those who hustle." - Unknown

From:        Trey Darley <trey@newcontext.com>
To:        Bret Jordan <Bret_Jordan@symantec.com>
Cc:        OASIS CTI TC list <cti@lists.oasis-open.org>
Date:        07/24/2018 06:10 PM
Subject:        [cti] Re: [EXT] [cti] Motion for Open Repository for STIX Enhancement Proposals
Sent by:        <cti@lists.oasis-open.org>

On 24.07.2018 20:25:29, Bret Jordan wrote:
> Isnât this premature ?  We do not yet have a process and have not
> yet decided on how this should be done. So I would not concur yet,
> with this request.

Hi, Bret -

Cf. the attached mail, New Context are already using SEPs, as will our
CES-21 partners (3 California utilities, and 2 national labs). As our
work on defining things like ICS-related Cyber Observables is widely
applicable outside of CES-21, we'd like to ensure that other
organizations in the energy sector are able to interoperate. Our
desire is that this work be owned by OASIS, protected by the Open
Repository's CLA.

The creation of this GitHub repository will allow a lot of good work
to be contributed to the STIX community. The existence of this GitHub
repository in no way precludes the TC from defining some other process
and voting that in down the road. Meanwhile, we'd like to crack on
with some work.

Bret, unless you can articulate some harm that would come about by New
Context and our partners contributing ICS-related STIX Enhancement
Proposals to the TC via an OASIS Open Repository I would respectfully
ask that you withdraw your objection.

Director of Standards Development, New Context
gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
"Though a good deal is too strange to be believed, nothing is too
strange to have happened." --Thomas Hardy

----- Message from Andrew Storms <storms@newcontext.com> on Tue, 24 Jul 2018 10:31:18 -0700 -----
Trey Darley <trey@newcontext.com>
Feedback on your proposed SEP Process

Trey -

As you know, my team has been part of the CES-21 project for nearly 4 years. The primary goals for New Context within that project has been to test and extend STIX as a means to create and share cybersecurity indicators and observables to support OT environments.

Since the introduction of requirements with regards to enhancing STIX (2 sponsoring organizations, working code, etc, etc), our project participants have been concerned about the long term ability and supportability of STIX for CES-21.

Over the past month, I've had the opportunity to brief our CES-21 partners (3 California utilities, and 2 national labs) about your proposed new extension process for STIX. To say the least, the feedback has been positive. They are excited about having a way to move forward that is better defined and supports interoperability.

Here are my notes from those meetings. I am also attaching a partial screen shot from a process flow diagram I used to explain the process in those meetings.

Current TC rules say that significant additions to STIX require:
- 2 sponsors (must be OASIS and CTI members)
- 2 example implementations
- Draft normative text
- Other requirements that have not yet been codified

These rules are not well defined and adversely affects our ability to influence the future of STIX and will likely have an unexpected outcome of vendor lock-in (instead of interoperability). CES-21 related STIX extensions that we currently have under development and/or waiting for release to the TC include:
- ModBus
- DNP3
- Patterning additions (variables, math functions)

- Whitelisting
- File Integrity Monitoring
- IEEE 2030.5, 
- Asset identification (and characterization)

The values of your new proposed process include:

- Common structure for submitting extensions
- Evens the playing field
- Removes politics, favoritism, $$
- Provides a way for anyone to create public extensions
- Metrics
-- Github records the number of times the extension was accessed
-- The TC can use these metrics to understand which extensions are most popular and subsequently make them part of the standard.

About CES-21:

CES-21 is a cybersecurity research and development program directed by the California Public Utilities Commission and the California Legislature. It is a collaborative effort between California-based investor-owned utilities (IOUs) and Lawrence Livermore National Laboratory. The main objective of CES-21 is to explore the next generation of Industrial Control Systems (ICS) cybersecurity, in the form of machine-to-machine automated threat response (MMATR), to protect electric grid infrastructure from emerging cyberattacks. Program research, development, & demonstrations (RD&D) leverages automation methodologies, data integration, advanced modeling, simulation, and analytics, as well as virtual and physical test beds, to provide tools and approaches for enhanced grid security and flexibility.

Andrew Storms
VP of Security Services

[attachment "Screen Shot 2018-07-23 at 5.27.47 PM (1).png" deleted by Jason Keirstead/CanEast/IBM] [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

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