Logging

[alevere]

I propose that the SLPF arguments include a new row named "log" that is a boolean. The default value is expected to be False where the slpf is not specifically instructed to log all traffic matching said rule. When this argument is set to True, it instructs an actuator to log the action that was taken with appropriate details regarding matched traffic.

[jmbrule]

It was my understanding that an argument provides additional detail or specifics regarding a command. When I think of 'logging', I think of it as a separate function, not a detail or precision of another function. It makes more sense to use an action such as 'start'.
Thoughts?

[jmbrule]

I will acknowledge that the use of an argument on a per command basis would simplify the process of having very precise logging (only log events that are a result of a particular command) and open to the notion of the command argument despite the fact that it is not consistent with how arguments are used elsewhere.

[Vasileios-Mavroeidis]

For allow or deny actions, logging should be part of the command, and yes this provides additional detail regarding a command.

What do we do in the case that we want to monitor a particular IP but not as part of deny or allow. This is also part of firewalls. So if we consider including logging as a command argument, then i would also recommend adding a new action target pair as Joe suggested above.

[jmbrule]

I see logging as a function that is different from other functions such as allowing or denying, therefore is another command as opposed to a refinement of an existing command. That was the motivation for stating that it should be a separate command with a different action (such as start). If the general consensus is that logging should be toggled on or off via a command argument, then we should not create another command that starts and stops logging. I suspect this would lead to some confusion and ambiguities.

[jmbrule]

I am suggesting that we adopt one or the other. Not both. Currently leaning toward a separate action, am open to the command argument route, suggest AVOIDING a dual approach of argument or distinct command

[Vasileios-Mavroeidis]

Because we are basing the development of the AP on the technologies we have experience there will always be pros and cons. Having the logging as an argument simplifies the engineering development of vendors that have this option as part of a firewall allow/deny rule.

Example: Allow IP to IP and LOG this rule

A separate action will offer higher granularity. This could be an action "LOG" (didn't check the LS) with targets ip_connection, ip_net, and rule number. The first 2 targets monitor a new connection (new firewall rules) the 3rd target requests logging an existing rule.

Because the logging action is again a firewall rule it is assigned a rule number, so we don't need to use start and stop. If we want to stop logging a connection we delete the firewall rule.

[jmbrule]

I believe Vasileios is making the case for a LOG command argument? Sounds good to me, just want to avoid having a command that is START logging (separate command) AND deny {log=TRUE}. Let's do one, or the other, avoid both

[Vasileios-Mavroeidis]

I actually support your approach but with more targets. Log ( new IP or existing rule number ).

If we have it as an argument it would need to always be part of allow or deny.

Maybe we would just want to investigate/monitor something without taking an action yet.

If we want to stop the action, we delete the rule. Even the log function would be a firewall rule but without allow or deny.

Again, im not against of populating an argument. But maybe we have use cases that we want to monitor something without having a particular action submitted such as allow or deny. That would be all.

[jmbrule]

Reviewing this thread: alevere proposed a command argument that would enable (or disable) logging of a command and subsequent events resulting from the command. (for example, deny log=TRUE would have the effect of denying the traffic and an entry in the log would be added every time the interface encountered the jmbrule and Vasileios-Mavoeidis suggested treating the logging as a separate command so that one could log events associated with an IP address, rule number etc.
Two questions:
ONE, @alevere , are you OK with modifying your original issue to add a new column on table 2.3-1 or do you prefer adding a new row to table 2.3-2? TWO, @Vasileios-Mavroeidis , are you OK with using the action 'create' and define a new target 'Logging_event' (or whatever target) or do you think we actually need a new action?

[Vasileios-Mavroeidis]

create "logging_whatever" will have to ingest (nest) the ip_connection etc. targets and the rule_number.

what about a simple "log" or "monitor" action that can utilize easily our targets. Less complexity to implement and less writing in the LS.

We also use our temporal arguments for start time and stop time. If we want to stop the process anytime we can use the delete action, even though the "stop" action would make more sense. Delete in the context of SLPF would be ok because most probably the log function is applied as a rule. But if we want to keep a consistency of how we use some terms between APs the stop action would be more appropriate.

What do you think? @jmbrule @alevere @davaya

[jmbrule]

I think Vasileios's logic is sound (BTW, sorry about the late reply). The gist of his position is that a simple action for logging coupled with our existing targets will be (relatively) straight forward to implement. My opinion: This is consistent with the openc2 approach we have been taking. I do have a MINOR concern regarding adding actions.
Consider this: Is it logical to conclude that the whole notion of logging is really a special case of the 'INVESTIGATE' action? From the packet filter's point of view, about all that would be involved with an 'investigation' of 1.2.3.4 would be logging when the address was presented, when you dropped it etc.
I will grant you that other actuators will have more sophisticated implementations of an investigate action, but to be quite blunt, that is an issue for another day in the context of another profile....

[davaya]

I think a "log" action on any applicable target makes sense.

I think a log-level argument (INFO, WARN, ERROR) might be appropriate, or multiple levels might not make sense, but the log action should at least be able to turn logging ON or OFF. You shouldn't start logging with a log action and stop it with a different action like stop or delete.

I think the word log is both well-understood and generally applicable across many profiles. I would not recommend using investigate as a substitute because it is far more ambiguous.

Those are all personal impressions, since you asked 😸. I'm not a firewall SME.

[jmbrule]

Sounds logical to me. May I suggest that we open an issue on the language spec (create a new action known as LOG) and close this issue with a note that this is a lang spec issue?

[sparrell]

Should we consider the “set” action. That was the plan when logging was discussed previously. I thought the action would be set, the target “logging”, the target specifier is the “level” (eg only blocks or only allows or error or 1-5, or on/off, ...)!and the actuator is the actuator. Ie logging is just another configuration parameter. That seems more consistent with the security technologies I know. The other option to consider is as an argument on existing command (eg action = block, arg= log).

I think more examples of real products and use cases are needed before deciding but I’m against a “log” action. I maybe could be persuaded with enough real world data to offset my experiences.

Duncan

iPhone, iTypo, iApologize

---

From: Joe Brule notifications@github.com Sent: Monday, March 9, 2020 3:02:49 PM To: oasis-tcs/openc2-apsc-stateless-packet-filter openc2-apsc-stateless-packet-filter@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [oasis-tcs/openc2-apsc-stateless-packet-filter] Logging (#114)

Sounds logical to me. May I suggest that we open an issue on the language spec (create a new action known as LOG) and close this issue with a note that this is a lang spec issue?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/oasis-tcs/openc2-apsc-stateless-packet-filter/issues/114?email_source=notifications&email_token=AANEXD2HBQ5SPQISUKCET7LRGVDOTA5CNFSM4KN4QTU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOIUWEA#issuecomment-596724496, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AANEXDYAPJEYBGUUPGLQTB3RGVDOTANCNFSM4KN4QTUQ.

[Vasileios-Mavroeidis]

@sparrell This approach does not look granular. Can you come up with JSON examples (structure) of how do we log an ipv4 connection or an existing rule using your approach? That would aid my understanding.

@davaya agree with the On/Off functionality

[alevere]

My opinion is that logging should be both at the argument and command level. Certainly, you may want to tell an actuator to log some aspect (whether that is a log command or set command). I dont think it makes sense to only support this way however, since every firewall I have worked with has log as a flag/argument at the rule level, and that is typically set in one atomic action at rule creation.

[jmbrule]

Respectfully disagree. My opinion is that LOG should be a command OR an argument, not both. There are advantages to limit the number of ways that one accomplishes a task

[sparrell]

To Joe's one or other but not both wrt logging - they actually are different commands. I agree we should try to minimize different ways to do the same thing, But if today's policies and today's technologies do distinguish between different levels of loggings (ie only on this command vs log all blocks) then we probably need to also. Update - given Alex's comments on call that most are per command, I withdraw my arugument and support arg.

[Vasileios-Mavroeidis]

@sparrell I edited my previous comment. I was saying " how do we block" whereas it should be "how do we log".

Alex is right that generally you can set the log flag to an allow or a deny rule, BUT you can also create a rule for logging/monitoring purposes only. Then our action/target pairs cannot acommodate this use case.

[Vasileios-Mavroeidis]

was looking at this issue again. Let me clarify and combine Alex's info and mine.

TWO cases for logging firewall rules (allow or deny) - logging rules individually or a block of rules such as whole access control lists (we can have multiple in firewalls). This can also be achieved with zones (that would make it three cases actually).

Functionality that we want to integrate into the AP:

1. The log function is part of an issued command such as allow or deny. For example, allow or deny packets that have the following source or destination address and log the packets that were allowed or denied.

This is achieved by adding an extra parameter to the issued firewall command/rule. In OpenC2 that means that we can integrate this functionality with an extra openc2 argument for allow or deny actions

2. The log function is not part of a deny or allow command but a function/command itself. For example, log packets having the following source and destination address or a block of addresses. This is pure monitoring capability for a particular defined reason.

This is achieved by introducing a new action that can use the targets that we already have, such as ipv4 and 6 connection and net

What about if we adopt one out of the two recommended solutions? Is it possible to use one option for both use cases?

Yes by using the solution in case 2 but it comes also with a cost, that is introducing extra overhead, which is our case is the need for a second command. If we want to enable the logging mechanism for an existing firewall rule that would require to issue one command only. Let's say log firewall rule 345, or log a particular ipv4_connection object.

If we want to issue a new block or allow rule, then we don't have the argument log in our specification. That would mean that we have to issue a second openc2 command only for logging purposes.

If we want to have one only addition in the AP, then solution 2 is the way to go. If we want to be granular and make life easy for the developer/adopters then maybe have both options is the way to go. Precise text on the suitability (and examples maybe) of the argument and the log action is of great importance (one is for newly issued firewall rules such as allow or deny, the other is maybe for monitoring purposes only, meaning no allow or deny is issued).

[sparrell]

I do think however we solve this (and my leaning based on above is 'both'), it should be for everything not just slpf - which makes me think language spec needs this as well

[dlemire60]

This issue was revisited in the 23 June AP-SC meeting. It seems to me that:

1) @alevere & @Vasileios-Mavroeidis have indicated that "every firewall I have worked with has log as a flag/argument at the rule level"; to me this points to having the BOOLEAN "log" argument in the commands that create & modify firewall rules. As a going in position I'd say this argument should be defined in the SLPF AP, as it's closely associated with the cybersecurity function whose OpenC2 interface is defined by the AP. There certainly doesn't seem to be any value in routinely requiring the extra overhead that Vaileios pointed out comes from forcing this to be two commands. If this feature begins to appear in multiple APs we'd then consider promoting it to the language spec.

2) Separately we hear there's demand (e.g., from the SCAP community) for OpenC2-based capabilities to configure logging / recording functions. As @davaya stated in the AP-SC meeting, that appears to be distinct enough to justify having a separate AP and/or additional functionality at the language level (e.g., the suggested "log" action) in order to properly address the range of use cases. DaveK suggested during the meeting that there were parties interested in creating that AP.

Bottom line: in this particular case, I think @jmbrule 's preference for having a single way to do things is a poor fit to the realities of the situation.

[alevere]

pull request put in place