Re: [cti-stix] Conceptul model for sighting

[Sarah Kelley <Sarah.Kelley@cisecurity.org>]

@Jerome - we did attempt to run the statistics tool (three times). We’re
running Soltra Edge, and we’re getting an error.

Below is the error and the command my team used (with password and user
and host
changed).  We followed the install instructions on git hub.

./cti-stats —user=noone --pass=‘password' —host=soltra --port=80
--use-ssl=False --validate-cert=False --taxii-stats
Traceback (most recent call last):
  File "./cti-stats", line 69, in <module>
    main()
  File "./cti-stats", line 63, in main
    args['--use-ssl'], args['--validate-cert'])
  File "/home/dwallmeyer/soltra_edge/cti-stats/lib/cti.py", line 115, in
taxii_poll
    process_stix_pkg(stix_package)
  File "/home/dwallmeyer/soltra_edge/cti-stats/lib/cti.py", line 74, in
process_stix_pkg
    obs_type =
str(type(i.object_.properties)).split('.')[-1:][0].split("'")[0]
AttributeError: 'NoneType' object has no attribute ‘properties'


Can anyone help troubleshoot?

Sarah Kelley
Senior CERT Analyst
Center for Internet Security (CIS)
Integrated Intelligence Center (IIC)
Multi-State Information Sharing and Analysis Center (MS-ISAC)
1-866-787-4722 (7×24 SOC)
Email: cert@cisecurity.org
www.cisecurity.org
Follow us @CISecurity






On 10/27/15, 10:26 AM, "Jerome Athias" <athiasjerome@gmail.com> wrote:

>I think we're doing well.
>I think the location and detection-method could be optional (in an
>effort of keeping things as simple as possible)
>
><source> observed <x> instances of <object>, <time-range> (via
><detection-method>) (at <location>) (with <confidence>) (...)
>
>
>After let's say two weeks of open discussions in the list, we could
>update the github and ask the TC Chairs to present the current
>conclusion/proposition during the next meeting. Then submitting it for
>an open request for comments for a period of, let's say 1 month before
>potential definitive agreement/validation
>
>@Sarah: regarding the relationships 'issue', there's an open
>discussion going on to know if we make it as a construct. I will just
>add, for now, that if you can't find a 'workaround', that I assume
>right now being finding the -relationship path- between top level
>object A and the underlying object B, this should be highlighted
>
>@Sarah (and all): did you run the statistics tool? :-)
>
>
>
>2015-10-27 14:56 GMT+03:00 Davidson II, Mark S <mdavidson@mitre.org>:
>> I’m feeling like the possible use cases mentioned so far might be
>> condensable into the following sentence structure:
>>
>>
>>
>> “<source> observed <x> instances of <object> at <location>,
>><time-range>,
>> via <detection-method>”
>>
>>
>>
>> This has decent (but not complete) overlap with Terry’s proposed
>>fields, so
>> maybe it means we are on the right track?
>>
>>
>>
>> As a side note, do we know how we are we capturing the outcome of this
>> discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1],
>>with
>> links out to more detail as necessary. (Note that decisions does not
>>mean
>> that everything in there is set in stone – it just means the TAXII SC
>>has
>> general agreement on the principle. For e.g., the REST API, there’s
>>still
>> plenty to work on). Once we get most people agreeing on most things for
>>a
>> particular discussion, we could document them in a similar fashion and
>>keep
>> track of the open items; e.g., if we can’t agree on <Some-Field>, let’s
>>mark
>> it as an open question and move on to another topic.
>>
>>
>>
>> Thank you.
>>
>> -Mark
>>
>>
>>
>> [1] http://taxiiproject.github.io/taxii2/#decisions
>>
>>
>>
>> From: cti-stix@lists.oasis-open.org
>>[mailto:cti-stix@lists.oasis-open.org]
>> On Behalf Of Sarah Kelley
>> Sent: Tuesday, October 27, 2015 7:18 AM
>> To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret
>> <bret.jordan@bluecoat.com>
>> Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>;
>> Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave
>> <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org
>>
>>
>> Subject: Re: [cti-stix] Conceptul model for sighting
>>
>>
>>
>> I am a huge proponent of letting (almost) anything link to anything. In
>> fact, limiting what can have an association/link/relationship with what
>>is
>> my current biggest frustration with Stix (we use workarounds to get
>>around
>> this limitation).
>>
>>
>>
>> I would add the possible use cases:
>>
>>
>>
>> My org observed 3 instances of this threat actor hitting our network
>>
>> My org observed 12 instances of the Poison Ivy TTP on our network
>>
>> Or even (though weaker):
>>
>> My org was hit by this particular campaign 27 times
>>
>>
>>
>>
>>
>>
>>
>> Sarah Kelley
>>
>> Senior CERT Analyst
>>
>> Center for Internet Security (CIS)
>>
>> Integrated Intelligence Center (IIC)
>>
>> Multi-State Information Sharing and Analysis Center (MS-ISAC)
>>
>> 1-866-787-4722 (7×24 SOC)
>>
>> Email: cert@cisecurity.org
>>
>> www.cisecurity.org
>>
>> Follow us @CISecurity
>>
>>
>>
>>
>>
>> From: <cti-stix@lists.oasis-open.org> on behalf of Jerome Athias
>> <athiasjerome@gmail.com>
>> Date: Monday, October 26, 2015 at 10:29 PM
>> To: "Jordan, Bret" <bret.jordan@bluecoat.com>
>> Cc: Terry MacDonald <terry@soltra.com>, "Baker, Jon" <bakerj@mitre.org>,
>> "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Cory Casanave
>> <cory-c@modeldriven.com>, "cti-stix@lists.oasis-open.org"
>> <cti-stix@lists.oasis-open.org>
>> Subject: Re: [cti-stix] Conceptul model for sighting
>>
>>
>>
>> I do agree with Terry and Bret last emails and find the thread
>>constructive
>>
>>
>>
>> Some use cases for bottom up (without full context for now):
>>
>>
>>
>> My org observed 12 instances of this malware artifact today (after AV
>> signatures update)
>>
>> My org observed 100000 hits from this ip address in the last hours (all
>> against ssh)
>>
>> My org observed 5000 times this excel file with macro (coming in
>>emails) in
>> the last 10 minutes
>>
>> My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007
>> (against our VPN portal) this week-end
>>
>> My org observed 3 binaires signed with this stolen certificate this
>>month
>>
>>
>>
>>
>> On Tuesday, 27 October 2015, Jordan, Bret <bret.jordan@bluecoat.com>
>>wrote:
>>
>> In terms of volume, I see the Sighting object dwarfing all others,
>>probably
>> by several orders of magnitude.  Following the sighting object I see the
>> relationship object being the next largest consumer of TAXII volume.  I
>>also
>> see the Sighting object along with the relationship object and its
>> assertions working in a very social side of threat analysis and
>>discovery,
>> where a lot of back and forth takes place.
>>
>>
>>
>> Another option I can see is the Sighting object as being a seed for
>> additional exploration or automated data enrichment.
>>
>>
>>
>> So let's make sure we get this and the relationship object figured out
>>and
>> done well.
>>
>>
>>
>> Bret
>>
>> Sent from my Commodore 64
>>
>>
>> On Oct 26, 2015, at 1:45 PM, Terry MacDonald <terry@soltra.com> wrote:
>>
>> Hi Jon
>>
>>
>>
>>
>>
>>
>>
>> -          Sensor Alerts – As an example, an IDS or other sensor
>>reports a
>> match on some indicator. You will likely have some contextual
>>information
>> like times, ip addresses, host names, what indictor was matched, what
>>was
>> really seen, which IDS or sensor reported the alert, etc..  You probably
>> don’t care about data markings, aggregate sighting information, and
>>other
>> fields. You probably do care about having compact efficient messages
>>due to
>> high volume.
>>
>>
>>
>> This is what I personally (speaking as myself) think of when I think of
>>a
>> Sighting. A description of an Observable Instance with some basic extra
>> context.
>>
>>
>>
>> -          Organizational Sighting Reports – As an example, consider
>>what is
>> needed when an organization reports back to an ISAC/ISAO that an
>>indicator
>> has been matched (or sighted).
>>
>>
>>
>> To me this is no different to the first case. If an Indicator has been
>> matched then a new Sighting object will be created under the namespace
>>of
>> the Organization. The Organization will then share that Sighting object
>>back
>> to the ISAC/ISAO (if the Org wants to) along with a Relationship object
>> (also under the  namespace of the Org) that maps the ISAC Indicator to
>>the
>> Org’s Sighting Object. This can potentially be accompanied with an
>>Incident
>> object or Report object to give extra context if required.
>>
>>
>>
>> -          Aggregate Sightings Analysis – Consider the information
>>structure
>> that is needed to enable effective analysis of aggregate data from both
>>of
>> the above examples.
>>
>>
>>
>> In my personal opinion it is up to consumers to use the collected data
>>to
>> make their own decisions. Every Organization has their own institutional
>> idea of trust. They alone know which sources of information make sense
>>for
>> them, their management’s risk appetite, the verticals they operate in
>>and so
>> forth. The analysis that one Organization performs to come to the
>>conclusion
>> of ‘High’ risk may actually be a ‘Low’ risk in another organization.
>>Each
>> Org must be ultimately responsible for its own analysis.
>>
>>
>>
>> But, that’s not to say that they can’t outsource that function to other
>> organizations. Dedicated third-parties specializing in analyzing
>>Sightings
>> to extract TTPs and match those to Campaigns and Actors will become more
>> prevalent. These third-party analysis services will provide analysis
>> customized to the Organization’s structure/vertical/risk appetite which
>>will
>> help them extract the ‘why and ‘how’ from the ‘what’.
>>
>>
>>
>> I believe that the separate top-level Sighting object will provide us
>>with
>> the basic structure to begin the higher level analysis. I believe that
>>this
>> will then help third-parties to generate more ‘upper-level’ STIX data –
>> Threat Actors, Campaigns and higher-order TTP in particular.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Terry MacDonald
>>
>> Senior STIX Subject Matter Expert
>>
>> SOLTRA | An FS-ISAC and DTCC Company
>>
>> +61 (407) 203 206 | terry@soltra.com
>>
>>
>>
>>
>>
>> From: cti-stix@lists.oasis-open.org
>>[mailto:cti-stix@lists.oasis-open.org]
>> On Behalf Of Baker, Jon
>> Sent: Saturday, 24 October 2015 2:10 AM
>> To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret'
>> <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com>
>> Cc: cti-stix@lists.oasis-open.org
>> Subject: RE: [cti-stix] Conceptul model for sighting
>>
>>
>>
>> The sightings conversation has historically suffered from a lack of
>>shared
>> understand of the sightings use cases and an attempt to address all the
>> related sightings use cases with one complex model that does not really
>> satisfy any single use case very well. I guess I am a fan of a bottom up
>> approach focused on the use cases that are seen in the wild today.
>>
>>
>>
>> At a high-level I think that we can talk about sightings in several
>>ways:
>>
>> There are probably others perspectives on sightings to consider as
>>well. My
>> recommendation is that we clearly state (use case)  each of the
>>different
>> kinds of sightings and that we independently flesh out the information
>> requirements.
>>
>>
>>
>> At the same time we need to consider what is done today in each of these
>> cases and what we think needs to be done in the future. I would like us
>>to
>> focus on developing a model for sightings that satisfies today’s needs
>>and
>> allows for expansion to what we think the future state should be. When
>>it
>> comes to sightings we simply don’t have enough experience to know what
>>is
>> really needed beyond supporting what people already do today.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Jon
>>
>>
>>
>> ============================================
>>
>> Jonathan O. Baker
>>
>> J83D - Cyber Security Partnerships, Sharing, and Automation
>>
>> The MITRE Corporation
>>
>> Email: bakerj@mitre.org
>>
>>
>>
>> From:cti-stix@lists.oasis-open.org
>>[mailto:cti-stix@lists.oasis-open.org] On
>> Behalf Of Bush, Jonathan
>> Sent: Thursday, October 22, 2015 8:48 AM
>> To: 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave
>> <cory-c@modeldriven.com>
>> Cc: cti-stix@lists.oasis-open.org
>> Subject: RE: [cti-stix] Conceptul model for sighting
>>
>>
>>
>> I definitely like the “state the use case first” approach here.  We
>>can’t
>> implement a data design until we know what we plan on doing with it.
>>
>>
>>
>> On the simplicity suggestion – YES!!  Simple, simple, simple.  We can
>>always
>> add fields later.  Let’s just get this implemented, baked into our
>>products,
>> and then we can see what we are missing.
>>
>>
>>
>> On the data structure – Seems to me that the big decision on this is
>>whether
>> or not we have a sighting object or EACH sighting (meaning, it
>>references
>> something and adds context like who saw it, date, etc…) or have a
>>combined
>> object that carries a count.  The former will offer more flexibility,
>>but
>> will mean more object instances.  The later is really just a summary of
>>the
>> former, which will be much smaller from a db size perspective, but we
>>won’t
>> be able to identify individual characteristics of each sighting
>>instance.
>>
>>
>>
>> Personally, I favor flexibility.  We can solve the size issue with
>>technical
>> implementation.
>>
>>
>>
>> From:cti-stix@lists.oasis-open.org
>>[mailto:cti-stix@lists.oasis-open.org] On
>> Behalf Of Jordan, Bret
>> Sent: Wednesday, October 21, 2015 5:42 PM
>> To: Cory Casanave
>> Cc: cti-stix@lists.oasis-open.org
>> Subject: Re: [cti-stix] Conceptul model for sighting
>>
>>
>>
>> I think a better place to start is how people or devices are going to
>> interact with an IOC-Indicator.
>>
>>
>>
>> 1) Human: I am going to see a list of IOCs in my work bench tool and
>>have
>> the ability to query that list for certain things as I do stuff.
>>Perhaps as
>> I start documenting an issue I am seeing in my network it could show a
>>list
>> of potential IOCs that match it.  I could then:
>>
>>             a) click a button that says "share a sighting" or
>>
>>             b) the software could be configured to emit a sighting every
>> time the IOC (think URL, IP address, Hash, filename, etc) is referenced
>>in a
>> report.
>>
>>
>>
>> 2) Device: A network device / security tool might be watching the
>>network
>> and either looking for IOCs based on a feed it gets from somewhere or it
>> might find bad stuff on its own and generate an IOC then query the repo
>>to
>> see if the IOC is already known.  In either case, the device could emit
>>a
>> sighting.
>>
>>
>>
>> While I appreciate the desire to cover every esoteric corner case that
>>might
>> ever come up, I think we should take a minimalistic approach to the
>>first
>> generation of the Sighting object..  It is always easy to add stuff,
>>but it
>> is really hard to take it away.
>>
>>
>>
>> I would argue that the bare minimum we need is:
>>
>>
>>
>> 1) Reference to what it is we are sighting
>>
>> 2) The person / organization that is making the sighting
>>
>> 3) A count of the number of times it was seen.
>>
>>
>>
>> Now yes, there is a LOT more things that COULD be added, and all of them
>> could be added over time.  For example (yes this will rub people the
>>wrong
>> way), data markings.  I would personally leave them out for now.  I
>>would
>> love if we could get to the point where we had to rev the sightings
>>object
>> spec to support data markings or something else because we had so many
>> people using it and begging for the feature.
>>
>>
>>
>> By taking the minimalistic approach we can more quicker and get people
>>using
>> it.
>>
>>
>>
>> Think:
>>
>>
>>
>> {
>>
>>             "type": "sighting",
>>
>>             "id": "foo.com:sighting-1234-1234-1234-1234",
>>
>>             "idref": "abc.com:indicator-4321-4321-4321-4321",
>>
>>             "count": "1222"
>>
>>             "producer": "tom and jerry"
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>> 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 Oct 21, 2015, at 15:17, Cory Casanave <cory-c@modeldriven.com> wrote:
>>
>>
>>
>> In the meeting today “sighting” was discussed. Below is the sighting
>> component of a conceptual model we are developing for threats and risks.
>> Note that this is a level more general than STIX (the model is being
>>mapped
>> to STIX), but perhaps we can share some ideas.
>>
>> Regards,
>> Cory Casanave
>>
>>
>>
>> <image003.jpg>
>>
>>
>>
>>
>> DTCC DISCLAIMER: This email and any files transmitted with it are
>> confidential and intended solely for the use of the individual or
>>entity to
>> whom they are addressed. If you have received this email in error,
>>please
>> notify us immediately and delete the email and any attachments from your
>> system. The recipient should check this email and any attachments for
>>the
>> presence of viruses.  The company accepts no liability for any damage
>>caused
>> by any virus transmitted by this email.
>>
>>
>> ...
>>
>> This message and attachments may contain confidential information. If it
>> appears that this message was sent to you by mistake, any retention,
>> dissemination, distribution or copying of this message and attachments
>>is
>> strictly prohibited. Please notify the sender immediately and
>>permanently
>> delete the message and any attachments.
>> . . .
>
>...

This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . .