Requesting guidance on Endpoint Security entitlement (com.apple.developer.endpoint-security.client) for per-process network connection telemetry on managed macOS

Privacy & Security General Entitlements macOS Security Endpoint Security

Created 2d

Replies 3

Boosts 0

Participants 2

Hi Apple Developer Forums,

We are developing a managed macOS security/monitoring agent for enterprise customers (deployed only to MDM-managed endpoints). Our goal is to collect per-process network connection metadata (e.g., which process initiated a TCP connection, destination IP/port, timestamps). We are not intercepting or collecting network payload/content—only connection metadata for security telemetry/compliance.

We previously explored options like:

sysctl PCB lists (e.g., net.inet.tcp.pcblist_n) / kernel structs (not stable ABI; appears private/fragile)
Aggregate TCP stats (sysctl net.inet.tcp.stats) which are public but system-wide only
proc_pidinfo() / PROC_PIDFDSOCKETINFO for per-PID socket snapshots (polling-based; limited / not event-driven)

It seems the supported, event-based approach for per-process connection visibility is EndpointSecurity.framework, but it requires the entitlement:

com.apple.developer.endpoint-security.client

Questions:

Is EndpointSecurity.framework the recommended/supported approach for per-process TCP connection events on macOS for a managed enterprise security agent?
What is the correct process to request approval for the Endpoint Security client entitlement under an Apple Developer Program team? (We were directed to post here.)
Which Endpoint Security event types are appropriate for capturing connect/accept/close style network events per-process, strictly for metadata telemetry?
Are there any platform/privacy constraints or best practices Apple expects us to follow for this use case (MDM-managed enterprise deployments)?

We can provide additional details (distribution method, signing, MDM deployment model, privacy disclosures) if needed.

Thanks!

Answered by DTS Engineer in 886420022

Is EndpointSecurity.framework the recommended/supported approach for per-process TCP connection events on macOS for a managed enterprise security agent?

No, EndpointSecurity won't really work for this. You can block sockets through es_event_uipc_connect_t, but that auth call doesn't (and can't) include the kind of data you're looking.

I think your best option would be one of the Network Extension points, but I've pinged Quinn and I'll let him provide his own suggestions on tha front.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

DTS Engineer OP

Apple

22h

Accepted Answer

Is EndpointSecurity.framework the recommended/supported approach for per-process TCP connection events on macOS for a managed enterprise security agent?

No, EndpointSecurity won't really work for this. You can block sockets through es_event_uipc_connect_t, but that auth call doesn't (and can't) include the kind of data you're looking.

I think your best option would be one of the Network Extension points, but I've pinged Quinn and I'll let him provide his own suggestions on tha front.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

DTS Engineer OP

Apple

FYI, it’s very easy to miss comments in a post so I’d recommend just replying with a new posts instead of commenting.

For our use case (per-process connection metadata: process identity, destination IP/port, timestamps, no payload inspection), would a Network Extension content filter (NEFilterDataProvider) be the recommended approach?

Yes, that's your best option. After a second look, our sample project here basically does exactly what you're describing.

Specifically, can NEFilterFlow provide reliable process attribution + connection metadata without requiring full traffic interception?

The main issue here is that NEFilterDataProvider cannot handle ALL possible network activity. It will capture "high level" traffic generated through "typical" API usage, but the lower level network APIs just don't "fit" within its API structure. As an extreme example, there isn't any way for the system to describe the destination URL for a stream of raw Ethernet packets. NEFilterPacketProvider can "see" lower level traffic, but I'm not sure the original app "source" information is available by the time you reach the packet filter.

That may not matter if you're simply trying to gather information about "normal" app[1] usage, it could be an issue if you're concerned about active attacks/security.

[1] While it is technically possible to "browse the web" by sending and receiving raw Ethernet packets, it's solidly in the category of "so miserably complicated that no one has ever built that product".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

scottfromaustin OP

19m

Thank you, this clarification is very helpful.

Based on your explanation, our primary requirement is per-process network connection metadata for typical application behavior (process identity, destination IP/port, timestamps). We are not attempting to inspect or reconstruct raw packet traffic, nor are we trying to handle extremely low-level or adversarial networking scenarios (ex. raw Ethernet packet generation).

Given that, it sounds like NEFilterDataProvider may be the most appropriate fit, even if it does not capture every possible low-level network path. Our goal is to monitor “normal” application-generated traffic on managed enterprise endpoints, rather than achieve complete packet-level visibility.

Could you please confirm:

Whether NEFilterDataProvider is the recommended approach for this type of per-process connection metadata (typical app usage)
Whether it provides reliable process attribution + remote endpoint information sufficient for this use case
If there are any specific limitations or edge cases we should explicitly account for in a managed enterprise deployment

Our deployment model is strictly MDM-managed macOS devices, and we are aiming to stay fully within supported/public APIs.

Thanks again for your guidance.