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

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):
Data-Org Provenance
Trust Management
Confidence Management

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

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