DKS21 - Profile Specificity - SLPF CSPRD Comment

Until we have many more actuator profiles, I think it is hard to determine how broad a profile should be. I believe this SLPF profile as constituted is really for two different functions and, as such, we are overburdening implementations with complexity and added unnecessary functionality.

SLPF, as drafted, covers two independent technologies. One major class is controls in many large cloud providers (e.g. AWS, Azure, ...) which implement stateless packet filters for ip-connection targets. Another class was is certain hardware vendors which produce stateless packet filters on ip-addresses but not connections (ie ip=1.2.3.4 but not ip=1.2.3.4, Dst-port=80). Both of these are combined in this specification and I believe they should be separate profiles.

As we develop more profiles we hopefully will develop guidelines on when to include in one profile and when to split into several. Since any given security device is allowed to implement more than one profile, I think it is better to have smaller, more granular, profiles rather than combine them. My criteria would be to ask if there is a use case for a quick, painless switch betweeen the two choices. If the answer is yes (eg switching from AWS SLPF to Azure SLPF) then they should be in the same profile. But if the commands are incompatible (eg switching from a device with allow ip-connections to allow ip-address) then I would consider them different profile. It is possible to map an allow-ip-address (eg. Allow arc-p=1.1.1.1) to an allow-ip-connection (eg. Allow arc-ip=1.1.1.1, arc-port-any, ...). However it is impossible to map most ip-connections (eg allow src-ip=1.1.1.1, Src-port=80) to ip-address without losing security controls and hence increasing security risk. Therefore I think they should be in different profiles.

Because we combing ip-addr SLPF with ip-con SLFP it adds complexity in understanding (the option to one or the other for consumers) and it adds implementation burden for producers (eg a cloud orchestrator that will never encounter the fairly rare unique hardware that comes ip-con to implement the capability for ip-con which adds code, adds complexity, IMHO adds security risk because of the added code which will not be used). Note my âfairly rareâ is a subjective opinion based on my career. I am not against supporting that functionality if someone needs it - I just dont think it should burden a very common, and growing functionality.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

openc2 message