Firewall vendor participation

-------- Original Message --------
Subject: Re: [openc2-actuator] Re: [EXT] [openc2-actuator] Re: Firewall
Profile: Target types and specifiers
From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Wed, April 04, 2018 12:43 pm
To: Dave Lemire <dave.lemire@g2-inc.com>
Cc: "Everett, Alex D" <alex.everett@unc.edu>, "Brule, Joseph M"
<jmbrule@radium.ncsc.mil>, "openc2-actuator@lists.oasis-open.org"
<openc2-actuator@lists.oasis-open.org>

The request for an 80% solution, is that from operators or actual actuator vendors? Meaning, are the firewall vendors coming and asking OpenC2 to produce a standard that is 80% there?

Bret

From: Dave Lemire <dave.lemire@g2-inc.com>
Sent: Wednesday, April 4, 2018 10:21:42 AM
To: Bret Jordan
Cc: Everett, Alex D; Brule, Joseph M; openc2-actuator@lists.oasis-open.org
Subject: Re: [openc2-actuator] Re: [EXT] [openc2-actuator] Re: Firewall Profile: Target types and specifiers

I often feel that we are going about this whole thing wrong, or completely inside out. Without the right people at the table, the probability that we get it wrong or design something that will not be adopted is high.

Then our #1 focus should be a strategy for getting the right people to the table. However, beyond creating and promoting a reasonably high-visibility standards effort with a well-known standards body (check), I've got nothing.

Horse, water, drink problem, I guess.

I'll note, however, that Joe and I have consistently heard feedback along the lines of "get us an 80% solution sooner" in several one-on-one conversations with interested parties. Are the people already at the table 80% smart on the essential matters?

Dave

From: Dave Lemire <dave.lemire@g2-inc.com>
Sent: Wednesday, April 4, 2018 7:00:29 AM
To: Bret Jordan
Cc: Everett, Alex D; Brule, Joseph M; openc2-actuator@lists.oasis-open.org
Subject: Re: [openc2-actuator] Re: [EXT] [openc2-actuator] Re: Firewall Profile: Target types and specifiers

Bret: I'm entirely sympathetic to your view regarding expertise but I also honestly think that we have to play with the team we've got. When we publish something that's wrong, the experts will emerge from hiding to tell us that. So I see the current effort as essentially forcing the process to get going.

Dave

On Tue, Apr 3, 2018 at 6:00 PM, Bret Jordan <Bret_Jordan@symantec.com> wrote:

I still hold to the idea that I am not sure we have the right people at the table for this. Yes many of us, myself included, have run very large networks with loads of firewalls and security devices, however, this is not enough. What we need are SEs and Architects from vendors that actually make these devices. It would be nice to figure out what these vendors actually do already, so that we can "standardize" on it. This will greatly increase the possibility of adoption.

Bret

From: openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org> on behalf of Everett, Alex D <alex.everett@unc.edu>
Sent: Tuesday, April 3, 2018 9:38:59 AM
To: Brule, Joseph M; 'openc2-actuator@lists.oasis-open.org'
Subject: [EXT] [openc2-actuator] Re: Firewall Profile: Target types and specifiers

My comments inline

From: openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org> on behalf of Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Tuesday, April 3, 2018 10:10 AM
To: 'openc2-actuator@lists.oasis-open.org'
Subject: [openc2-actuator] Firewall Profile: Target types and specifiers

Actuator Profile SC,

I ran into some interesting questions while going through the target types and request feedback on the following five questions:

QUESTION ONE:
The current draft has the ip-connection target type which is: src address, dest address, src port, dest port and next protocol
The current draft also has the ip-addr target type
So the question is, do we really need the ip-addr? It seems to me that we can just have the ip-connection target type and you don't have to specify the complete five-tuple. Logical?

--- We could, though I think most of the use cases would be block this IP as a source or destination, so that may be odd to think of using ip-conn. I think you would have to make two calls to do that which would be counterintuitive. I think the common case is you just want it blocked, you dont care about the details.

QUESTION TWO:
During one of the AP biweeklies, one of the members stated we need to be able to specify if the deny or allow is for the inbound or outbound traffic.
I cooked up a specifier called 'interface' and then say the allowable values are 'ingress', 'egress' or both.
So the question is: are these the correct terms? Or should we use something else such as outbound, inbound, or internal, external?
Also, I assume the default value should be 'both'. Correct?
--- I think this could get too complicated.

Blocking an IP seems to me to be something that is easy to understand and probably implement for a packet filter or firewall. Directionally blocking is more of a feature of a stateful firewall. If we decide to support this for a stateless firewall, it gets pretty complicated quickly. We probably then need to support TCP flags, group names, ACL names, physical and logical interfaces, policy names, etc. I just dont know how a packet filter service would know exactly what to do with the command.

QUESTION THREE:
During one of the AP biweeklies, one of the members suggested we have a 'heartbeat' target type for query. The use case is along the lines of the orchestrator wants to confirm that the actuator is up and running and sends a 'query heartbeat' and I suspect that the appropriate response code is 200 (or 401)
So the question is: Is 'heartbeat' ok for the target type?
BTW, I did get two comments on this topic:
Comment one: We don't need the heartbeat target type because you can handle that at layer four.
Comment two: Rather than have a 'heartbeat' target type, simply define 'heartbeat' as one of the specifiers in the (preexisting) openc2 target type.
--- I am leaning towards this is a good feature and leaning toward comment 2.

QUESTION FOUR:
The persistent option results in a permanent rule that will be retained in the event of a powerdown, restart or reset. The running option results in an ephemeral rule that is active while the firewall is running, but not retained after a reset.
There are two questions here: Question one, which should be default (there was a slight preference for persistent during the last teleconference). Question two, should we bubble this one up to the LSC or do you see it as more of a niche?
-- I would lean towards persistent. You really dont want an undetermined outcome just because of a reboot or reload of rules. Also, many firewalls and packet filters dont support this transient only config.

QUESTION FIVE:
In the current language spec, we have the following command options: start-time, stop-time and duration.
I would argue that for the firewall profile, we can use 'stop-time' OR 'duration' but we probably should not have both because having both leads to some ambiguity wrt how one builds the command.
Question, should we have stop-time or 'duration'?

-- duration seems more logical to me. Just keep in mind that there are probably few firewalls that would support this option initially.

-Alex

---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

openc2-actuator message