[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions
|
Yes Great post. (Apologies catching up!) Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company +61 (407) 203 206 |
terry@soltra.com From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org]
On Behalf Of Barnum, Sean D. Great post. Thanks Cory. sean From:
<cti-users@lists.oasis-open.org> on behalf of Cory Casanave <cory-c@modeldriven.com> Patrick, Great perspective – it is a common and difficult problem to balance scope, complexity, extensibility and simplicity. The inconvenient truth is that
Cyber security is not simple, but we don’t want to introduce arbitrary complexity either. Well, I’m probably putting a target on my back, but I’m going to suggest that some things that may seem simple do, in fact, introduce more complexity
and restriction as reality sets in. (remember when XML was the simple alternative, then we got XML Schema and 100 extensions – same for java). I have noticed a set of recurring themes that if we could deal with in a consistent way, may help this difficult balance. So just consider these
as some thoughts from the peanut gallery. ·
Big Vs. complicated. A very small and simple instance document may be described by a large schema. A large schema in and of its self is not necessarily complex.
What is complex is:
o
When you have to insert a lot of “stuff” the simple case doesn’t need. Some of this may be inevitable, but it can be mitigated by good
design.
o
When there are many ways to say the same thing. This is unclear semantics and/or redundant elements.
o
When it is not clear how to do the simple thing. This can be mitigated with use case specific documentation (like the “idioms”)
o
When large schema/vocabularies/models are not modular so you can look at manageable “chunks”. ·
String encoding. A very common “simplification” is to substitute a reference to a thing with a name or ID usually a string. E.g. victim:
”Joe Smith”. While this seems simple it causes multiple problems that result in downstream complexity. A reference to a thing should always be a type for that thing. E.g. victim: -> person: {name:”Joe Smith”}. Reasons for this are:
o
What is in the “string” is unclear and tends to be inconsistent, making interoperability difficult.
o
When other “facts” need be said about the thing, you have a place to put them and don’t try and encode it in complex strings.
o
If the string is an ID, there is no consistency for the basis for the identifier. ·
My hierarchy is not your hierarchy. While it seems simple to put things in a hierarchy, hierarchies tend to be specific to a use case or perspective. Independent
entities should be independent and referenced, not embedded as an attribute. The complexity introduced by some implementation frameworks for references can be a problem – but can be mitigated by a good framework/API. Problems with embedding include:
o
The same entity may show up in multiple places, resulting in confusing redundant data.
o
Embedded entities may lack identity, making analysis difficult.
o
It is hard to “say more about” such an embedded entity or to reference it later. ·
There is more to say When you try and put everything someone may need to know in a single “data package”, the packages become large and very
coupled to a single perspective of what must or can be communicated. Having an architecture that allows for accessing additional data – be it extended vocabularies or more information on Joe Smith allows the structures to be smaller, simpler and less coupled.
Building the expectation of linking into the architecture allows for this simplicity, which also provides for extensibility. This can also be done in “secure” or partially connected communities by building linking into security and using intermediate data
cashes.
o
Note: My view is that this is solved: every reference should be a URI, how you “dereference” that URI is where your secure boundaries come
in. ·
Realistic extension Some of our technologies fight extensibility and ad-hoc mechanisms are to be built-in to support it, sometimes these mechanisms add complexity.
On the other hand, assuming there will never be a need for extension is unrealistic in an open community. Sometimes it is better to:
o
Use a technology that allows for extension naturally
o
Be realistic about where extensibility is really needed. When it is – use the extensibility mechanisms for everything. E.g. all vocabularies
are an “extension”, even if some are considered well known and curated. ·
It is obvious what it means Much design and implementation experiences come from closed or smaller environments than CTI. If, for example, we are integrating 3 systems
in company XYZ there is a shared understanding and culture of the team. What things mean, constraints and formats tend to be worked out dynamically – and this is practical in such an environment. In a large and dynamic community it is simply amazing how different
people interpret the same things. In a community environment there is a need for clear and precise semantics and, wherever possible, automated validation. Loose specifications will never be interoperable. If not interoperable, what is the point? ·
This is the only technology we will need Whatever it is, there is a favorite of the day and a desire to “just do that”. Well, not everyone will have the same favorites and the style
of the day changes (sometimes it seems like we are the fashion industry). Over-committing to a single technology builds that technologies limitations into your solution – which may look really stupid in 5 years. Separation of concerns is vital. ·
Real complexity As a final thought – recognize “real complexity” – if what you are trying to do and communicate is not simple, don’t expect a simple result.
The challenge is recognizing and supporting the real complexity in as simple a way as possible. If complexity is being introduced for other than “real” reasons, what is introducing them? This got longer than intended, sorry about that! If we can find our way to deal with these issues in a consistent way with good design and a supporting
implementation framework that makes them easy to deal with we can have a usable balance between simplicity, scope and extensibility.
-Cory Casanave From:
cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org]
On Behalf Of Patrick Maroney There is a common theme running in our important discourse. It is important for Vendors and those focusing on narrow Use Cases to understand the complexity of APT Intrusions. We understand and *completely*
support many of the arguments made for simplicity and easily addressing narrowly focused use cases. If I just need to send a list of IP Address, Domains, etc. to security appliance, then an efficient/consistent/simplified mechanism is absolutely a key CTI
requirement. Those of us who have been dealing with the full scope of APT Targeting, Compromise, Lateral Movement, Entrenchment, repeated Mapping/Exploitation of Victim Organizations and Infrastructure, etc. for
many many years (pre Titan Rain) are also key stakeholders in "Our Thing". We are not pushing for "Complexity" just for complexities sake: we are pushing these higher dimensional representation concepts because this complexity is part of the reality we operate in on a daily
basis. If we can't model all of the key elements of Adversary, TTP, and Target Domains, we can't change the Cyber Battle Space dynamics. Doing so globally, across sectors, in real-time, is the "Holy Grail" we seek. No one said this would be easy, but it
is a much much better use of our collective energies in comparison to another decade of playing APT Whack-A-Mole and counting Body Bags. Hopefully I'm not triggering a new wave of "Less Filling" <==> " Tastes Great" 😁 On to specifics (great discussion by the way) (1) IncidentType is critical to some of the highest value CTI Use Cases, including mandatory Incident Reporting (in some cases, required under law in 72 hours after detection!). Automating, standardizing/normalizing,
and aligning Incident Reporting across Stakeholder (2) C2 is one of the highest value CTI Elements one can convey. "One of the most common forms of indicator seen describes a pattern for TCP traffic beaconing to a specific command and control (C2, C&C) server. This idiom describes creating such an indicator in
STIX." The presence of attempted or active C2 is one of the strongest indicators of "Wildfire": Active compromise of an asset/network. If you see it you are pwned, only question is the degree. C2 can be a component of all Kill Chain Phases (Lockheed Martin™) , from "Recon" to "Actions on Intent". We could consider the "one way to do things" principle, but given the importance of semantically and temporally characterizing C2 in the Operation Domain, we would need to ensure we can clearly convey
in all required contexts. (3) Similar comments to C2 on "Exfil". Although we have a running joke in certain Domains ( "...but no evidence of Exfiltration"). "Exfil" is the "Game Over" state in CTI Operational Domains. (4) "Malicious.CybOXObject" It would be great to start focusing on a number of long standing enumerated type issues in CTI. In some cases they are non-sequitur with current realities, incomplete, bloated, etc. We should also
be mindful of related standards and use these and/or map to their taxonomies. Some of the enumerations in other standards have similar issues with currency/relevance, but we should adopt these wherever possible and engage with those communities to fix them
"in one place" (Jerome Athias has one of the best perspectives on these standards, where they intersect, conflict, etc.: Jerome would be a great resource to lead this effort) Patrick Maroney _____________________________ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]