- Man in the Middle (MITM) and;
- Denial of Service (DoS)
Man in the Middle (MITM) attacks are possible when your employees’ machines are on networks controlled by a potential attacker; the attacker can use their vantage point to intercept communications between your sync server and clients, and then attempts to impersonate the server. If successful, an attacker could gain full control over the Santa rules deployed to the client. This would allow the attacker to add, modify, or delete rules, including rules to block legitimate security software and permit malware.
Denial of Service (DoS) attacks are possible when your sync server does not authenticate the Santa clients connecting to it. Without client authentication, a potential attacker can send your sync server garbage data making it difficult, if not impossible, to use the server as intended. With the server gummed up, it becomes possible for further attacks or malware to execute without you being able to filter out the signal from the noise, making detection or mitigation difficult or impossible.
Moroz can be deployed and hosted anywhere, giving you full control over its server-side TLS configuration. This makes it possible to issue it a unique certificate from your own pinned CA and fully implement this mitigation.
Unfortunately, Upvote can only be deployed on Google App Engine (GAE), which uses a CA defined by Google for everything running on GAE. Pinning that CA’s certificate still allows a potential attacker to create their own Upvote server on GAE and conduct a MITM attack if they’re able to observe network traffic from your Santa clients. Though pinning to the GAE CA is does not protect against against that scenario, Fleetsmith automatically does so as a partial mitigation, since this is the best that can be done without product changes to GAE by Google.
Upvote does not immediately support this functionality, but does provide a stub in its code in which admins can write their own authentication function to receive and handle these certificates.
Unfortunately, Moroz does not provide any mechanism for client verification, leaving it vulnerable to these attacks as well.
Upvote’s does a good job detailing this strategy of “progressive lockdown.” But, in short, the process is to first spend some time simply monitoring your fleet with Santa to understand all the binaries being executed on it and build an initial whitelist. After a period long enough to build confidence, the Santa clients can be shifted piecemeal into lockdown mode without blocking any of the programs seen in the initial monitoring period. Once the entire fleet is in lockdown, an elusive goal has been achieved: without large disruptions to employees, an administrator can be assured that all of the software running across the fleet is known to be safe!
This begins an ongoing state where the database of permitted and blocked software in Upvote grows over time as employees install and use new software in the fleet. The social voting model Upvote uses allows employees to start using new tools, and get them permitted by Santa, without the administrative overhead normally associated with centrally-managed binary management tools. If an employee does approve a piece of malware, the need for a critical mass of approvals before a global whitelist is enacted will slow its spread through the fleet, granting administrators more time to respond, alleviate, and proactively block new threats.