Following this as I am working on a similar problem.
+1,
Won't be able to say much on our strategy working through this, however we are still facing some of those same hurdles.
Yeah, you're going to have a bad time. I currently have the same issues in the Health industry.
I've had this tab open in my browser for a while now - there may be some tidbits of info that you find useful: Apple Enterprise and the 17.0.0.0/8 disclosure
First up: Some of those criteria will absolutely not be solvable, but generally from what we've seen they're less set in stone than security people at financial institutions make them out to be - And decisions regarding each can sometimes not actually be their call to make. Get the risk team involved, and people who understand the actual regulatory requirements imposed by governing bodies.
With that said..
Two issues with different hoops to jump through/arguments to make.
- Conceptual trust of Apple ("They want direct access to our devices?! What?!")
- Technical trust of Apple ("Okay, we're alright with devices phoning home, but we can't implement it securely due to how our network has been constructed")
First one is easy, Apple's AE/SE/CE team can probably help out if arguments are falling flat. We've found if you get #1 agreed upon, suddenly security/networking teams can become constructive rather than complete roadblocks.
I work for an MSP targeting almost exclusively large financial institutions, so we've gotten pretty good at the second issue too.
We've developed a technical pattern for deploying APNS that works, but is not endorsed or approved by Apple so there's some inherent risk that Apple could make massive protocol changes overnight and we'd be back to the drawing board.
Probably worth pointing out it's not just push you need to get a DEP workflow working end to end, there are a raft of 'enterprise incompatible' Apple services that need to be contactable, we've had to do extensive research and documentation to maintain a list of 'actually-required' services, addresses, dns names etc that Apple use, instead of just 17/8.
Caveat: Your life will be easier and everything will work better for longer if you follow Apple's technical guidance to a T.
I can't go into detail on solutions publicly because our clients are sensitive about anything network security related but Microsoft is enforcing similar requirements for some O365 traffic, so there could be procedural and technical precedent in some organisations.
Or just turn the whole issue on its head and go zero trust.
Is the financial an ApplePay partner? If so, there is already an inherent trust to Apple with real $$$ attached to it. A tiny packet to phone home to Apple for device management is nothing compared to that.
APNs by it’s nature just needs a route out. That one firewall rule actually deepens security than what a 4kb outbound packet will compromise it.
If there is really a concern about data over 5223, one thing I have seen at customers in this space is to put alerts if the traffic goes over a threshold more than a typical APNs push.
One huge argument I see from security teams is that APNs does not allow for packet inspection... since certificate pinning is in play, any man in the middle attack is negated, most security teams don’t seem to get is that packet inspection in and of itself is a man in the middle situation. They can’t have it both ways.
There is a great video presentation on Jamf.com from JNUC 2017 called “A Push Odyssey” I really suggest showing this to any APNs naysayer because it explains the whole process better than any Apple doc I have seen to date.
Just watched the presentation by @bradtchapman from the 2017 JNUC and I have to say it was great! I will be using many of his points when working with IT Security and the network admins to get things working correctly with our proxy.
Many thanks to Brad and to @MarkMelaccio for recommending it.
@bradtchapman Are you in the #proxylife channel on Slack?
