[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: EDR Spec - Updates and Topics to discuss
|
Section 2,3, or 4 of agenda? Ie ready to approve(2), to discuss for approval next meeting (3), or to discuss what future PR’s needed (4). Please look at agenda
https://meet.lucidmeetings.com/meeting/280246 and edit acordingly. Eg in section 2 either delete what I have or replace it with what I have in 3. Or put some in 2, some in 3 and some in 4 accordingly. You should be able to edit the agenda. If not, that’s good to know also and we can do realtime at beginning of meeting. But better to do ahead of time if possible. -- Duncan Sparrell sFractal Consulting LLC iPhone, iTypo, iApologize I welcome VSRE emails. Learn more at http://vsre.info/ From:
openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org> on behalf of Vasileios Mavroeidis <vasileim@ifi.uio.no> Hello everybody, I wanted to keep you updated and provide some comments regarding the EDR profile (https://github.com/oasis-tcs/openc2-ap-edr/blob/working/oc2edr.md) that we
may want to discuss in today's meeting. Martin and I have also created a couple of pull requests. Currently the profile addresses only the Response part of EDR. —————— 1) Related work (section): The first bullet point is to be removed. The second bullet point is to reference related specifications. Should we reference the LS or the architecture doc when it is ready? 2) Actuator profile references - 3 have only URLs 3) RFC3552 non-normative most probably should be removed 4) At this point, the specification is all about Endpoint Response, as it is also indicated in Section 2. I would like to ask Martin to propose how we move forward regarding the detection engine of EDRs. Is it easy to address? Is it something
that the spec needs to address? Can we configure the EDR programmatically to add signatures, heuristics? Is this addressed in combination with another technology? If the task involves a lot of research and writing, does it make sense to split the current spec
to 3? The parent EDR spec will reference the ED and ER specs. That way, we can have the ER spec out faster than the ED spec. 5) All over the document and in particular in section 2.3, we are saying "OpenC2 Consumers that receive ... command". Even though a consumer can be the actuator, I think we would need to replace "Consumers" with “Actuators” or change it
to Consumers/Actuators, also according to our definitions. 6) The "contain file" is written in detail, and I guess, based on a particular technology/implementation. I propose just to write "Quarantines a file" because other technologies may perform this process differently; for example, the EDR
may use encryption to make it inaccessible. 7) 2.3.4.2 allow file. "This command should not be issued towards a file which has not previously received a 'deny file'..." - I won't agree with that. You are requesting this information from the orchestrator, but a file could be denied
directly from the EDR. In that case, the orchestrator has no direct visibility to that. 8) Section 2 - Number 3: "The definitions of and conformance requirements for these types are contained..." What does "types" refers to? 9) 2.1.5-1: " A hostname (can be domain or IP) for a particular device..." - This is the same as in the SLPF spec. We may need to change the hostname to host so that we can “correctly" accommodate both IPs and domains. 10) In 2.3.7.2, 2.3.9.1, and 2.3.11.3, we have not included the consumer/actuator behavior. 11) We need to be more consistent in our writing style. For example in Section 2,3, "OpenC2 Consumers that receive a ABC Command:" and "OpenC2 Consumers that receive ABC Commands:" - I changed, I think, everything, based on the first case. 12) To do: Update the table of contents 13) To do: Recheck the conformance statements for quality and consistency in wording - I haven't checked this section in detail. —————— Best, Vasileios Mavroeidis Research Scientist Digital Security Group University of Oslo |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]