Palo Alto Hardening

People tend to forget that the Palo Alto isn't just a stateful firewall, but because they've had experience with deploying them (Netscreen, ASA, Checkpoint, etc) that's how they set them up.
Yes, people will attach inspection profiles to their policies and think they get all the protection they paid for - but there's a lot more to hardening a firewall than just flipping a switch.

I'm going to go over a few hardening techniques for Palo Alto that should help you secure your network.

Everything is an application
If your users are using custom ports for services (8080 for example), don't create a service for it, create a custom application. Provided you set up the signature correctly, this will prevent other applications from hijacking this port.

Organize your network
The Palo Alto should be the default gateway for everything in your network. It should be your router on a stick. This way you'll have full visibility on East/West as well as North/South traffic. Most people will be hesitant to do this because you'll lose bandwidth (Nexus switches push an excess of 900Mbps whereas the Palo Alto are well under 300Mbps). This is something you'll have to speak to your clients about, is the faster accessing of a server in the DMZ worth the risk?

The DMZ is the DMZ
Continuing with the last topic, your DMZ is exactly that, it's demilitarized. Keep the DMZ out of your trust network, don't put your publicly accessible web server and your DC in the same zone. Even with the Palo Alto in the middle of your network, if you have a web server and your DC on the same segment and your server gets compromised - you'll be switching packets over without your noticing. That's where a VM-series Palo Alto comes into play (something I'm not going to get into here). If you have to, create a second DMZ; the point is to keep things out of your trusted zone.

Be paranoid
Palo Alto endorses a concept of a "zero trust network" and so should you. You can't trust anyone in your network so you have to lock things down as tight as you can to prevent anything that'll come up. If you can afford the decryption hit to your throughput (usually 50%), turn it on. Enable file blocking to and drop any file you can't inspect; unless you have TRAPS, you as a firewall admin can't rely on McAffee to do its job.

Another good practice is to use the 'continue' option in file blocking. This will prompt the user when a download occurs for them to confirm it's legitimacy - this will help stop drive-by-downloads.

There can be only one DNS
Have your DNS server be the only host on the network (yes you can have more than one, but the point is it's something YOU control) sending egress queries. There's no reason for Joe Blow in marketing to be contacting a public DNS server.

Sink it
Setting up a single DNS server makes it difficult to identify who on the network sent the original request. Palo Alto has a feature which enables it to passively intercept DNS queries if a bad host is attempting to be resolved it will respond with a bogus IP; this is your sinkhole address. Once that happens the host will attempt to establish a session with it and you'll have a policy to pick it up and your logs will show the original sender.

Authorize everyone
Speaking of identifying users, you should be using User-ID everywhere possible. This will let you deploy policies specifying specific groups and users as a source as well as identify users who are doing things they shouldn't be.

Keep up your policies
I'm going to outline a small list of policies you should keep at the top of your policy list to help secure your network

Rule	Purpose/Description	Caveats
Dynamic Blocklist	Uses Spamhaus’ DROP (don’t route or peer) list to block ingress and egress traffic. This list consists of known bad addresses.
Block by Country	Blocks ingress traffic from countries which the client does not conduct business with. Particularly useful if NATs are in place.	Mobile users may have issues connecting remotely. Ingress GlobalProtect permit-any policy may be required above this.
DNS Sinkhole	Uses Passive DNS inspection to perform dynamic DNS resolution on bad FQDNs. This policy allows logs to be generated for these requests.
Drop High-Risk	Denies traffic for high risk (risk level 5) traffic.	Applications which are common-use may fall into this category, specifically SMTP and HTTP-Video; these will need to be overridden to a risk of 4 or lower.
DNS from Server/DNS from Any	Only allows DNS traffic from a dedicated DNS server.	DNS server use will need to be enforced. May only be applicable to corporate zone (guests will be allowed to Google or Level3 DNS).
53 from Any	Prevents traffic being tunneled out port 53.
Block by Category	Specifying the URL categories in its own policy prevents the Palo Alto from passing this traffic through the rest of the Content-ID engine, which saves CPU cycles. Useful on larger devices.

Don't risk it
One thing I didn't include above was any inspection policies. You'll want to apply a block to any application with a risk rating of 5. Yes, SMTP and some others have a risk of 5, well override these ones. It's easier to override 3 or 4 applications (if you legitimately need them) than it is to risk your network.

They're there to be used
A lot of Palo Alto firewalls I've seen don't user Zone Protection or DoS Protection - they're there for a reason, turn them on.