Re: [cti] Re: [EXT] [cti] Motion for Open Repository for STIX Enhancement Proposals

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

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
www.ibm.com/security

"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.

-- 
Cheers,
Trey
++--------------------------------------------------------------------------++
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 -----

To:	Trey Darley <trey@newcontext.com>
Subject:	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 P  707-477-4335

[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]