[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Draft Threat model for IMDDOS COAs
Sorry, forgot I was supposed to respond to this. I think I understand where you’re going with this:
So this is like a one-off recommendation, specific to that sighting of the bot. It’s not a general recommendation that “if you find this bot, you can remediate it by doing X”. I think that’s what was confusing
me, I didn’t realize there were tools that were planning to recommend (but not direct) COAs to other tools for specific sightings. Hopefully I’m following that correctly anyway. In regards to getting system information in STIX…we’d previously discussed a new “Asset” SDO to capture that information…but others thought that it was straying too far from “threat intelligence” and getting
into the asset management space. It may make sense to assume some kind of boundary object here that isn’t defined in STIX. John From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Hi John, The mini group has been working on identifying a couple of use cases for COA. If were to solve all of them, we would be doing this for a long time so we took a stab at putting our thoughts on timelines for
the various features. We plan to discuss this with the wider community in the Tuesday working call or the full TC meeting…still waiting to hear back on which week that will be. Hopefully that will help clarify the confusion. John: when you say “the COA should apply to the host identified by the sighting” do you mean: The COA that was actually taken should also be considered but that’s not in the model as of now. John - On your latter scenario, I’d have the same question...are you recommending the COA, directing it as part of like an orchestration capability, or reporting on it? I see the report having recommended/suggested COAs tied to indicators, sightings, malware etc. Orchestrators might take the recommendations and add more details to the COA based on the organization policy,
situational awareness etc. This COA would go to the actuators/enforcers who will act on it and return back some response. In STIX 1.x there was the notion of Suggested, Requested and Taken COA and I think it still makes sense and we should use it in some form
either as properties or relationships. John - Separately, I don’t think Identity really captures the concept of a “host”. Identity is really an organization or an individual, STIX deferred having an “asset” SDO to capture the concept of a host. I wasn’t sure which SDO to use for the internal host against which the sighting was made so assumed it was the identity. We need the IP address (at that time) of the victim. The orchestrator can then try to
determine who owned that IP at that time before executing the COA. What’s the best way to get the IP/other attributes of the victim? Thanks, Jyoti Technical Leader, CTO office Security Business Group, Cisco Systems Inc. From: "Wunder, John A." <jwunder@mitre.org> I think this is just me not understanding where the COA minigroup is headed, not that what you put together is confusing. Anyway, when you say “the COA should apply to the host identified by the sighting” do you mean:
The Damballa report had both (talked about what they did, and had some recommendations for what others could do). On your latter scenario, I’d have the same question...are you recommending the COA, directing it as part of like an orchestration capability, or reporting on it? I think the answer might be different in the
different scenarios. Separately, I don’t think Identity really captures the concept of a “host”. Identity is really an organization or an individual, STIX deferred having an “asset” SDO to capture the concept of a host. John From: "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Hi John, I cooked this up late last night and there is no particular reason for calling it ‘applies-to’ vs. anything else. The idea was that the COA should apply to the host identified by the sighting. In the example
shown here the COAs are atomic (delete registry key, block the process that is reaching out to the C2 domains, block the process that is reaching out to the TLD domain) and there is a higher level COA (IMDDOS malware removal) that is using these atomic COAs
(I called this relationship parent-of for lack of a better term). We discussed this example during the mini group call today and will be updating the model for a more real use case – ie. When a sighting is made, the identified host needs to be quarantined and then a series
of steps to remove the malware need to be done. This can be captured by 2 COAs – “Quarantine host” and “Malware cleanup”. What I’m struggling with is if these COAs should be related to the Sighting or directly to the Identity (identified host). Thoughts? Thanks, Jyoti Technical Leader, CTO office Security Business Group, Cisco Systems Inc. From: "Wunder, John A." <jwunder@mitre.org> Hey Jyoti, This is super comprehensive, thanks! I had a question for you…right now you have COA tied to Sightings as “applies-to”. What data does that indicate? That the COA was actually applied to the case described
in that sighting, or that it COULD apply? We’ve done some explorations of that concept and I was curious what you were thinking. John From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Hi, Based on the discussions in the COA mini group, I extended Rich’s threat model for IMDDOS with some COAs and relationships. We can work through this in the COA mini group call later today. Thanks, Jyoti Technical Leader, CTO office Security Business Group, Cisco Systems Inc. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]