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
Another good overview
On Saturday, 28 November 2015, Jordan, Bret <email@example.com
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.
Sent from my Commodore 64
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
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.
+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.
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."
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.
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.
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.
Wouldn't an asset just be linked using the already existing facility of @idref on ExploitTarget?
Not sure something new needs to be created...
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 <firstname.lastname@example.org>
Date: 11/27/2015 01:49 AM
Subject: [cti-stix] Asset: the missing piece in your puzzle
Sent by: <email@example.com>
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
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: