You just need to add the time element in the sequence. Something happened, then some defined time later this other thing happens, them some system or network checks were made, then some other thing happen within a defined time frame.
The act of downloading a PDF for example, is not always bad. But a PDF downloaded to a machine, followed by the download of three EXE files within 45 seconds, and the opening of a new outbound encrypted session, usually means it is not going to be a good day.
Thanks,
Bret Bret Jordan CISSPDirector 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 these two points. It hard to understate how often this kind of 'complexity' is required to describe things correctly. I know in the early days of sharing CTI via CSV files it was very common to have data that while was correct lacked the conditions to be accurately used as CTI due to the lack of structure and sequence of events. Here is a very simple example.
Lets say you are doing analysis on malware and find that the infection starts uses a dropper hosted at evil2015.com and when the malware successfully installs on a victim host its checks to see if it in Internet accessible location by reaching out to innocuous domain like say www.google.com or download.microsoft.com. So if you loose the sequence here and just query all your proxy logs for all three of the domains you will get tons of results that are useless, but not wrong. If the CTI data was instrumented to say evil2015.com and then one of these two from the same host shortly there after is a high probability of an infected machine. You don't know that from just having a host reach the evil2015.com domain.
Including these these the innocuous domains in the CTI data is useful for both the COA side but also developing TTPs of Threat Actors as some pick particular hosts to validate Internet access and it is more valid indicative data about who might be on the far end of the keyboard. (Yes it is not any where enough, but bread crumb trails are that way...)
Mark Clancy Chief Executive Officer SOLTRA | An FS-ISAC and DTCC Company +1.813.470.2400 office | +1.610.659.6671 US mobile | +44 7823 626 535 UK mobile One organization's incident becomes everyone's defense.
I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security | www.securityintelligence.comWithout data, all you are is just another person with an opinion - Unknown "Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like toFrom: "Grobauer, Bernd" <Bernd.Grobauer@siemens.com>To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>Date: 09/21/2015 12:07 PMSubject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard?Sent by: <cti@lists.oasis-open.org> Hi,stepping back from the choice of binding for a moment, I would like toexplore a bit, how much the next major version of STIX might differfrom what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board.Here is the overview of the indicator entity/concepttaken from page 13 ofhttps://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdfLet me propose the following simplifications:- version: Keep.- negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of howthe indicator is to be handled and is a real pain for implementation,even though it is hardly ever used(Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw thoseout, too).- Title: Make the field mandatory, but it may be empty.- Type:Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and wherethe intended semantics could not be communicated witha reference to a COA.- Alternative_ID:Unsure, probably keep. - Description:- There should be exactly 1 description field (which may be empty).Yes, this precludes fancy schemes of having different descriptionsfor different audiences/access levels, but those should amountto less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication ofthe standard.- There should be exactly one text representation, and that should *NOT*be html on account of security issues with rendering HTML in thebrowser. Chose Markdown, RestructuredText or whatever.- Short_Description:Remove: I am tired of receiving indicator objects in whichtwo or three out of three of the fields "title", "description", "short_description"are empty -- one description field should be plenty.(Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, sowhy the big fuss about description fields?)- Valid_Time_Proposition:Timing info for indicators is badly needed, but I have yet to encounter usageof it. Can we come up with sensible guidelines of how to use the field?It should only be kept if we can...- IndicatorExpressionIn the present specification, this field can eithercontain what is essentially a logical formula (codified as a tree)of indicators or an observable composition.- Remove logical operations: allow only to reference a listof indicators that constitute the present indicator.- If you want to do complicated and/or/not-reasoning aboutobservable stuff: that is essentially a signature,so find a signature-language of your choice (includingand/or/not-combinations of CybOX observables, if thatis what works best) and formulate the signatureas a test mechanism. - For everything else: find a way to encode observablepatterns as simple key-value pairs and include/reference a listof them here. Should work fine for the majority ofcurrent use-cases. At most, allow a structured list thatgroups basic observable patterns (key-value) pairs withrespect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism.- Kill_Chain_Phases:Define *ONE* standard STIX kill chain and work with that.Being able to include alternative models is nice, butcomplicates tooling quite a bit ... and, remember, thisis an exchange format, so one common kill-chain modelunderstood in the same way by everybody will work best.- Test MechanismsMake this a stand-alone entity/object rather than partof the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX.- Likely_Impact.Remove: I have never encountered it being used and havea hard time coming up with a convincing use case.- Suggested_COAs: Use yet-to-be-designed relationship mechanism.- Handling:Replace with some new mechanism for marking stuff withhandling information.- ConfidenceKeep: we need a simple way to distinguish high-confidencefrom low-confidence indicators.- Sightings: Find some other way to do sightings (cf. the discussion onthe mailing list)- Related_*: Use yet-to-be-designed relationship mechanism.- Producer: Either simplify drastically or better yet, leave awayand consider for the next but one major release.Like I said above: this as an experiment of being very simpleindeed (though my mind is probably too convoluted withall things CTI to come up with the super-simple thing).I am sure some of it is too simple, but with the currentversion of STIX we have already one extreme of complexity --to map out our design space, we need to get a feelingfor the other extreme as well, I think.Kind regards,Bernd--------Bernd Grobauer, Siemens CERT
|