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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: RE: [cti-stix] STIX 2.0 Specification Questions


 

Hi!,

 

We also need to keep in mind (not something that we need to down tools and look at straight away), but we need to ensure COA’s can be constructed in such a manner that tooling infrastructure at a later point in time, can act on these COA’s if it is transmitted to them.  For example a COA might be to block an IP address to log when it see an IP address.  We need to be able to represent this in a manner which is vendor neutral but provide the framework for vendors to then perform these actions when they receive them when they use a common taxonomy.

 

This could then be tied into the playbook idea as well such as “How to handle an unauthorised device on your network”, or “Responding to a C2 alert notification”.

 

Regards,

 

Dean

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Sunday, 14 August 2016 2:11 PM
To: Craig Brozefsky
Cc: Allan Thomson; Jason Keirstead; Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] STIX 2.0 Specification Questions

 

I agree with Jason...  We really need a way to make sure the concept of a COA works, can be used, and can evolve over time.  I also think having them linked to a Playbook is probably the most correct way to do it.

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Aug 11, 2016, at 09:13, Craig Brozefsky <cbrozefs@cisco.com> wrote:

 

Allan Thomson <athomson@lookingglasscyber.com> writes:


I think its reasonable and a good idea that it could do both.

For me, COA should be very flexible so that someone can be very
specific if they want to and provide their own actions (outside of
openC2) if needed.


Playbooks strike me as being customer specific, and not something that
is exchanged.  It is an organizations instruction set for the IR team,
and it can include anything from "contact legal" to "nuke and pave the
host" and have all sorts of logic and decision making embodied in it.

Considering that, I'm not sure what role it plays in STIX as a intel
_expression_/exchange standard.  We are preferring to use a rather generic
and open-ended definition of CoA, and "run/reference playbook X" is just
a CoA for us.

--
Craig Brozefsky
Principal Engineer, AMP Threat Grid
Cisco Security Business Group
+1-773-469-8349

 


This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.



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