We've got a department on our network using a piece of higher-security software. The software audit came back and indicated FIPS 140-2 encryption is required when the traffic is going across any network other than ours.
I've started looking into what that would take on our firewall so that our GlobalProtect endpoints and IPSec connections could be made compliant but I wanted to see what the common consensus here might be from others who may be using the feature. I'm not crazy about the console port being locked out of config mode.. it's handy to have that when we need to do a more extensive design change that may result in a loss of connectivity or Panorama management. I'm figuring the H1 link encryption and enabling FIPS-CC Mode itself will be disruptive and require outages even with an A/S HA setup for the loss of console access is concerning (we've got it in a locked rack ... I know those rack locks aren't really "secure" but it's in a locked datacenter as well).
I guess my question is, is it worth going through this or would it be better to find an alternative like a piece of software or another hardware solution (perhaps even a smaller dedicated PA just for these connections) we can provide for this specific purpose?
Is the requirement for the traffic to only pass FIPS 140-2 enabled devices, or for the traffic to only traverse FIPS 140-2 compliant encryption while in motion outside of your network?
In the latter i'd dare to venture you only need to build a sufficiently secure ipsec tunnel
in regards to encrypted HA1: this is always a good idea (and best practice): to enable it 'in production' you can already extract and import the certificates from the certificates page (little buttons at the bottom) before you enable encryption, if you enable heartbeat backup before enabling encryption, the cluster should withstand the temporary disruption of switching to encrypted HA
in regards to needing to comply fully, how 'locked' is the dataroom; will it withstand to an acceptable and reasonable degree any attempts to get in (are the walls floor to ceiling, or raised floor to dropped ceiling, is there a cage, CCTV, guards, ...)?
That's a good question.
The way they said, it sounded like the data had to be encrypted to that level while in transit across 3rd party networks... we have a point-to-point circuit across an ISP to our other campus that would qualify. Also, we've discussed having some of this data available in patrol vehicles over a cell network via a Cradlepoint device with an IPSEC VPN to our Palo... this would also fall under this category.
What I wasn't sure on was that the company required that we prove the hardware is FIPS certified. Them asking this question in the first place seems like that they'd want that enabled.
I didn't realize HA1 encryption was best practice. The two devices are in the same room and in the same rack with a direct connectioni so I never worried about traffic interception.
The room security is pretty good but oddly they didn't really ask about it. I think they focus on the encryption aspects and less on physical security.
well the device is certified:
HA1 encryption falls into the same physical security category as disabling the console port: someone could insert a sniffer between the firewalls and intercept config and other live data in cleartext (or if it travels across a network)
You may want to ask if this mode is required, or if you just need to be able to meet the standards. Enabling FIPS is a good security decission, but it does require some downtime per firewall to implement (the cluster should be able to handle this) and will come at a few drawbacks (you'll also need to 'up' the security of your management interface through a certificate and TLS profile, passwords will require a password profile, etc. )
That definitely makes sense although wouldn't it be more difficult to do when the firewalls have a Twinax cable directly plugged in to each other for the HA and no networking hardware in between? The HA cable would have to be disconnected from one and inserted into another device to have that opportunity. It's in a locked rack in a locked room.
The console was my other primary concern. I understand why FIPS mode would disable CLI access on it but what does recovery look like at that point if we push a config that causes a loss of connectivity? I would think that I could always just plug into the management port with my laptop and configure a compatible IP/Subnet to talk to it directly but that's assuming the config push didn't mess up the management interface config. I'm assuming, in that situation, a reset of the device would be required?
I'll definitely ask about this.
In maintenance mode you're able to assign previously saved, named, config file to load after the next boot and recover from such a bad config, but i'm not entirely sure this is still available in FIPS mode
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!