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] Asset: the missing piece in your puzzle


Hi list,

attached some documentation regarding, from an Information/Data Model
point of view, the (Cyber) Asset concept.

IMPORTANT:
when understood by all, and if consensus about its importance in/for the future;
I will use it to demonstrate why and how it is important for (and will
help to drastically simplify) Relationships and Sightings (and a lot
of other stuff) constructs

Best regards




2015-11-30 19:53 GMT+03:00 Wunder, John A. <jwunder@mitre.org>:
> FWIW the biggest problem I’ve encountered working incident response systems with the current STIX asset type (AffectedAssetType) is the lack of an external asset ID. Or, at least, my ability to figure out where to put an external asset ID.
>
> So I agree w/ Jerome that would be a good place to start (once we finish outlining the use cases and close some of these other topics).
>
> John
>
>> On Nov 30, 2015, at 11:37 AM, Jerome Athias <athiasjerome@GMAIL.COM> wrote:
>>
>> From my experience: consider Organisations/Person/Automatons/Hardware
>> as top-level assets constructs
>> But I strongly recommend to have at least a minimal Organisation
>> construct (Person we have with CIQ) and IT-Assets we know them
>> (Hardware could be excluded for now)
>>
>> Benefits of Organisations identification or characterization (even
>> minimal construct):
>> Org-Vocabulary
>> Data-Org Provenance
>> Trust Management
>> Confidence Management
>> and A LOT MORE
>>
>> One Org B can be an asset or Org A (e.g. a country)
>>
>> Asset Identification specification is a very good starting point, imho
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2015-11-30 18:13 GMT+03:00 Patrick Maroney <Pmaroney@specere.org>:
>>> It would be good to first agree on "what" an Asset "Is":
>>>
>>> (1). Aren't Assets "things" owned by, or of Interest to,
>>> Organizations/Entities?
>>>
>>> (2). Organizations/Entities may indeed be "Assets" as well, but only in the
>>> context of specific use cases?
>>>
>>> Sent from Outlook
>>>
>>>
>>>
>>>
>>> On Mon, Nov 30, 2015 at 6:43 AM -0800, "Jerome Athias"
>>> <athiasjerome@gmail.com> wrote:
>>>
>>> Fair enough we can keep that for later.
>>> I will try to list all the points in the current model offering a link to
>>> "assets"
>>>
>>> On Monday, 30 November 2015, Wunder, John A. <jwunder@mitre.org> wrote:
>>>>
>>>> Has somebody written up the use cases for asset information? I can think
>>>> of the following:
>>>>
>>>> 1. Representation of asset identity (or I suppose full characterizations?)
>>>> to coordinate incident response. (I believe this is part of what Joep is
>>>> saying)
>>>> 2. Representing *types* of assets that are targeted by a particular
>>>> TTP/attacker (MITRE laptops running Windows 7). Here I think we need to
>>>> disambiguate a few things: targeting of vulnerabilities/weaknesses
>>>> (CVE-XYZ), targeting of platforms (Win7), targeting of asset roles (web
>>>> servers), targeting of supported business or mission functions (financial
>>>> systems), targeting of supported employees/users (John Wunder at MITRE). (I
>>>> believe this covers the other part of what Joep was saying and what Pat was
>>>> saying in the other thread)
>>>> 3. Asset risk analysis & characterization (listed in the STIX use cases
>>>> wiki, though IMO it’s a bit of a crossover use case because risk
>>>> incorporates much more than just threat)
>>>> 4. What am I missing?
>>>>
>>>> I think once we further outline the use cases we could make more progress
>>>> on what that means for the language. For example, are existing mechanisms
>>>> (ITIL, the NIST specs) good enough? Is the current AffectedAssetType in STIX
>>>> good enough?
>>>>
>>>> I can write up a use case for #1 because it’s right in line with the work
>>>> that I do. Can anybody else tackle the others? In the meantime, maybe on the
>>>> lists we can close out the sightings and data markings topics before diving
>>>> too deep into this one?
>>>>
>>>> John
>>>>
>>>> On Nov 29, 2015, at 9:14 AM, Jerome Athias <athiasjerome@GMAIL.COM> wrote:
>>>>
>>>> Another good overview
>>>>
>>>> http://www.mitre.org/sites/default/files/publications/pr-15-2592-overview-of-mitre-cyber-situational-awareness-solutions.pdf
>>>>
>>>> On Saturday, 28 November 2015, Jordan, Bret <bret.jordan@bluecoat.com>
>>>> wrote:
>>>>>
>>>>> Good point Joep.  Please offer up a proposal for what you would like to
>>>>> see based on your experience with your tool.  I would love to see it and
>>>>> better understand it.
>>>>>
>>>>> Bret
>>>>>
>>>>> Sent from my Commodore 64
>>>>>
>>>>> On Nov 28, 2015, at 7:49 AM, Joep Gommers <joep@eclecticiq.com> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> This is a interesting discussion. My 0.02$:
>>>>>
>>>>> Rob McMillan from Gartner:
>>>>> “Threat Intelligence is evidence-based knowledge, including context,
>>>>> mechanisms, indicators, implications and actionable advice about an existing
>>>>> or emerging menace or hazard to assets that can be used to inform decisions
>>>>> regarding the subject’s response to that menace or hazard”
>>>>>
>>>>> Inspired by Robert M Clark:
>>>>> "Intelligence is about reducing uncertainty. Uncertainty in a situation
>>>>> of conflict or uncertainty around business objectives (also known as
>>>>> “business risk”). In the context of CTI cyber focus, conflict can consists
>>>>> of any competitive or opposing forces/action resulting from the divergence
>>>>> of two or more parties’ ideas or interests. Example include uncertainty
>>>>> around topics of electronic crime, terrorism or espionage.
>>>>>
>>>>> Reducing uncertainty requires that intelligence obtain information that
>>>>> the opponent in a conflict prefers to conceal – directly or indirectly
>>>>> through analysis of available information. A typical goal of intelligence,
>>>>> also seen with the users of CTI, is to establish facts and then to develop
>>>>> precise, reliable, and valid inferences (hypotheses, estimations,
>>>>> conclusions and/or predictions) for use in decision making or operational
>>>>> planning or actions.”
>>>>>
>>>>> Key to expressing applicability of intelligence is being able to include
>>>>> assertions on what “blue” components are impacted by “red” forces. This
>>>>> includes victim information (like we do in TTP), asset classes impacted
>>>>> (like we do in Incident), etc. I think it is a grave misconception that
>>>>> threat information does not include information about what potentially is
>>>>> impacted by a threat and how that might evolve in the future. The closer an
>>>>> intelligence producer is to the impacted entity, the more granular they can
>>>>> describe what is impacted. All within the realm of responsibility of a
>>>>> threat analyst, of threat intelligence practice and of threat management
>>>>> process. For example being able to express that certain threat impacts any
>>>>> organization with online banking services, or payment processing facilities
>>>>> or software of a certain version etc. or the database behind URL online
>>>>> banking.com/x.aspx or any computer behind a firewall running windows 95 or
>>>>> anybody in the oil and extraction industry or anybody in belgium between
>>>>> april-15 and may-15 etc etc.
>>>>>
>>>>> If this should allow detailed modeling of asset technically, I have no
>>>>> opinion on. But the fact that any of the above examples need to be able to
>>>>> be communicated in a uniform way as part of a CTI standard for me is a
>>>>> no-brainer.
>>>>>
>>>>> Real-life examples: in our architectures, we are forced to use additional
>>>>> proprietary protocol exchange between platforms not using STIX because some
>>>>> of these “affected” or “targeting” statements are difficult to impossible to
>>>>> make in STIX. While all done by threat analyst, in a threat management
>>>>> context, inside a threat intelligence contract for a threat management
>>>>> budget informing the state of threat of an organization.
>>>>>
>>>>> So I wouldn’t personally wave more first level entities from the “blue”
>>>>> world away as quickly as that. I might even argue that having them part of
>>>>> other entities sometimes makes things more complex and hard to understand
>>>>> and apply. Nor do I nessecary agree with a “Asset” entity.. Simply providing
>>>>> some context IMO.
>>>>>
>>>>> J-
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret"
>>>>> <bret.jordan@bluecoat.com>
>>>>> Date: Friday, November 27, 2015 at 5:30 PM
>>>>> To: Richard Struse <Richard.Struse@HQ.DHS.GOV>
>>>>> Cc: Aharon Chernin <achernin@soltra.com>, Patrick Maroney
>>>>> <Pmaroney@Specere.org>, Jason Keirstead <jason.keirstead@ca.ibm.com>, Jerome
>>>>> Athias <athiasjerome@gmail.com>, "cti-stix@lists.oasis-open.org"
>>>>> <cti-stix@lists.oasis-open.org>
>>>>> Subject: Re: [cti-stix] Asset: the missing piece in your puzzle
>>>>>
>>>>> +1 Rich...  We have a hard enough time coming to consensus on seemingly
>>>>> easy things.  Lets first build a bridge that solves the issues we know with
>>>>> the current idioms and then lets gain massive adoption.  Once we have those
>>>>> two things, we can look at other things.
>>>>>
>>>>> Lets not put the freeways before the horse and buggy, or even lets not
>>>>> put the cart before the horse.  Or more in line of where we really are at,
>>>>> lets first figure out how to ride and tame a horse.
>>>>>
>>>>>
>>>>> 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 Nov 27, 2015, at 07:14, Struse, Richard <Richard.Struse@HQ.DHS.GOV>
>>>>> wrote:
>>>>>
>>>>> I agree completely.  Just because something (like asset information) is
>>>>> important and could be helpful in understanding the potential impact of a
>>>>> threat doesn’t mean that STIX or any component of CTI needs to define that
>>>>> information model.   We need to keep a laser-like focus on Cyber Threat and
>>>>> build bridges to other communities that are looking at asset, configuration
>>>>> or vulnerability information.
>>>>>
>>>>> From: cti-stix@lists.oasis-open.org
>>>>> [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Aharon Chernin
>>>>> Sent: Friday, November 27, 2015 8:31 AM
>>>>> To: Patrick Maroney; Jason Keirstead; Jerome Athias
>>>>> Cc: cti-stix@lists.oasis-open.org
>>>>> Subject: Re: [cti-stix] Asset: the missing piece in your puzzle
>>>>>
>>>>> I am 100% behind giving us the ability to communicate asset information.
>>>>> Just not sure it should be in STIX, or OASIS CTI for that matter. If we can
>>>>> do this at a higher level than CTI, then we can use the same asset standard
>>>>> for vulnerability, compliance, and threats. We could even use it outside of
>>>>> the information security space.
>>>>>
>>>>> I say we continue using exploit target until we can figure out how to get
>>>>> STIX out of the asset business.
>>>>>
>>>>> Aharon
>>>>>
>>>>> From: <cti-stix@lists.oasis-open.org> on behalf of Patrick Maroney
>>>>> <Pmaroney@Specere.org>
>>>>> Date: Friday, November 27, 2015 at 7:18 AM
>>>>> To: Jason Keirstead <jason.keirstead@ca.ibm.com>, Jerome Athias
>>>>> <athiasjerome@gmail.com>
>>>>> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
>>>>> Subject: Re: [cti-stix] Asset: the missing piece in your puzzle
>>>>>
>>>>>
>>>>> ExploitTarget only represents where the "pointy end" of the stick is
>>>>> pointed (attack surface/vulnerability), not the organization or assets
>>>>> behind same.  Some of us share the view that there needs to be a top level
>>>>> object that represents the Victim(s) and their Assets.
>>>>>
>>>>> Patrick Maroney
>>>>> President
>>>>> Integrated Networking Technologies, Inc.
>>>>> Desk: (856)983-0001
>>>>> Cell: (609)841-5104
>>>>> Email: pmaroney@specere.org
>>>>>
>>>>> _____________________________
>>>>> From: Jason Keirstead <jason.keirstead@ca.ibm.com>
>>>>> Sent: Friday, November 27, 2015 8:08 AM
>>>>> Subject: Re: [cti-stix] Asset: the missing piece in your puzzle
>>>>> To: Jerome Athias <athiasjerome@gmail.com>
>>>>> Cc: <cti-stix@lists.oasis-open.org>
>>>>>
>>>>>
>>>>>
>>>>> Wouldn't an asset just be linked using the already existing facility of
>>>>> @idref on ExploitTarget?
>>>>>
>>>>> Not sure something new needs to be created...
>>>>>
>>>>> -
>>>>> Jason Keirstead
>>>>> Product Architect, Security Intelligence, IBM Security Systems
>>>>> www.ibm.com/security | www.securityintelligence.com
>>>>>
>>>>> Without data, all you are is just another person with an opinion -
>>>>> Unknown
>>>>>
>>>>>
>>>>> <image001.gif>Jerome Athias ---11/27/2015 01:49:35 AM---From
>>>>> https://www.sans.org/critical-security-controls to ISO 27001, through the
>>>>> NIST CSF (#1 Identify
>>>>>
>>>>> From: Jerome Athias <athiasjerome@gmail.com>
>>>>> To: cti-stix@lists.oasis-open.org
>>>>> Date: 11/27/2015 01:49 AM
>>>>> Subject: [cti-stix] Asset: the missing piece in your puzzle
>>>>> Sent by: <cti-stix@lists.oasis-open.org>
>>>>>
>>>>> ________________________________
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From https://www.sans.org/critical-security-controls
>>>>> to ISO 27001, through the NIST CSF (#1 Identify), NIST Risk Management
>>>>> Framework, SP 800-53... ...
>>>>> If you don't properly manage your Assets in cybersecurity: you will FAIL.
>>>>>
>>>>> Information obtained from the data that you will manipulate and
>>>>> exchange need to be linked to your Assets, the Assets of others
>>>>> (Supply Chain or Adversaries).
>>>>>
>>>>> So -again-, I invite you to look at
>>>>> http://scap.nist.gov/specifications/ai/
>>>>>
>>>>> NB: While not perfect, and I can comment further with pleasure on
>>>>> where/why, the Asset concept/construct or relationships (i.e. through
>>>>> GUIDs) is, imho, NEEDED.
>>>>>
>>>>> PS: I will try to put effort on documenting where the current model(s)
>>>>> are currently weak regarding this domain
>>>>>
>>>>> Best regards
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>>
>>>>>
>>>>
>>>
>

Attachment: STIX_Asset.pdf
Description: Adobe PDF document



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