APNS question for people that work in financial services

[flyboy]

All,

I'm fighting a horrible up-hill battle to get push notifications approved at my org. We are a financial services institution and therefore are very risk-averse when it comes to opening up traffic to and from the internet. To that end, push notifications have never been allowed here since we cannot proxy and SSL intercept the traffic. To date we've been ok with that since manually installing configuration profiles has been an option. Well, enter user-approved kernel extensions and all that's changed.

Is there anyone else out there that works in financial services, or another highly regulated environment, that's been able to successfully support push notifications? If so, how did you architect and implement your solution?

My challenges are the following:
- external DNS lookups are not allowed -- must be done by the proxy
- all traffic going to the internet must go through an authenticated proxy session
- proxies are explicit, not transparent.
- SSL intercept required
- Outbound traffic must be scanned for PII (Personally Identifiable Information) and blocked if any is found.

Ideas?

[tomt]

Following this as I am working on a similar problem.

[drheiner]

+1,

Won't be able to say much on our strategy working through this, however we are still facing some of those same hurdles.

[Aaron]

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

[wilesd]

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.

[MarkMelaccio]

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.

[tomt]

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]

blushes

Glad it helped!

[tomt]

@bradtchapman Are you in the #proxylife channel on Slack?