The facts about ADP and Zenefits: Response to the claims made by Zenefits [pdf]
adp.com
Disclosure: I work at a competitor to both - posting this because I find it generally interesting from a data security and integrations perspective.
adp.com
Big corp. starts illegally stealing data through improper means and not following T&C of small-funded startup
and there would be an uproar.
All those fluff tech-sites that treat Apples new Iphone with incremental changes as "big news" would suddenly have months of juicy news to bash the big corp to the point where their bigger media-parent companies would follow suit and damage the big corp indefinitely.
Maybe folks should just call "a spade a spade" here.
The startup violated the T&C of ADP and whether or not ADP is 100% honest of the server-volume from this company, the startup still committed an illegal action.
You can "disrupt" industries all you like, but when you break explicit contracts, you can't go crying on social media about it and expect things to work out for you.
As far as PR goes, ADP won with this line:
"We’re willing to work with our clients who use Zenefits, and with Zenefits directly, to find a solution that fulfills our clients’ needs and protects their data."
Here's a fun question... Did Zenefits ever agree to the TOS?
IANAL - It seems as though they did agree.
So basically a user of Zenefits gives Zenefits the authority to act as an agent on behalf of them. So, technically when Zenefits accesses the ADP site they are legally seen as the authorized user themselves.
If I knew that a service was going to act on my behalf towards another party and that other party wasn't happy about the way that service behaved towards them. I might question my use of letting that service act as my agent.
Zenefits is actually pretty smart here because they can say "our users want this, they've agreed to our ToS that says we act on their behalf".
Imagine Zenefits was simply a broker and your broker said to you "ADP just shut off my access to them so I can't use their service, how about we use XYZ instead?". As long as I trust my broker is providing value then it doesn't matter what payroll service I use. So, if Zenefits is confident people value their service above the service a payroll service provides, then they will most likely win in this case.
Integrating with ADP is easy, but like so many other enterprise software/platform integrations, each project has to be taken independently. Zenefits doesn't want this but ADP doesn't have any real reason to change things.
How are those two statements not contradictory? Seems to me that if integration was easy (read standardized) it would be agnostic of, not specific to, who was integrating.
Pretty much anything for which recipe-style cookie-cutter patterns are documented, for instance, fits this description.
It's exactly things like this why I think most programmers and architects should spend at least a year or two working in a large corporation. They'll be exposed to all kinds of situations that just don't exist in a startup (or even most SMBs).
But these are all complicated in that you could literally take the smartest person in the history of the world and make about the same rate of progress as if you had taken a pretty average person to do the same thing. These sorts of problems tend to be related to wicked problems. For example, there's a bazillion side effects to consider, meetings to be had about "what does this field mean to you actually?," and other things that are of business importance but are a complete snore to the programmer implementing them. You're not talking about whether to use singly or doubly linked lists or which datastructures to use in an integration almost ever, but you're talking about how well it will scale from the perspective of a business and how its own rules and patterns of use work.
Business algorithms might be something both hard and complicated of a topic, but unless your business is actually something technical such as algorithmic trading, scientific & technical research, etc. your business domain skill level is probably more about depth of knowledge than whether you're really smart or anything in itself.
Also, SOAP was a very popular "standard" but those of us stuck in the pits of writing tons of XML-RPC SOAP code for years knows that it was hardly ever more standardized in practice than "REST" is today.
They're one of those companies that tell their enterprise customers that they are not allowed to update to a new point release of Java.
Data security (SSNs, banking info) is difficult, but they're table stakes in the payroll and benefits space (ex., how do you securely share personal information across different benefits providers).
Honestly, my main takeaway is I'm happy our company built everything (payroll and benefits) in-house from scratch.
We worry less about integrations issues, and it helps with security when you have more control over everything.
It's been extremely difficult building everything from the ground up, and I've definitely questioned our approach (more than once I said, "Why don't we just integrate with X?"), but I think this validates the path we've taken.
This is a lesson I'm going to take away for whatever other software/service I may end up working on.
This is not a good take away. The same could be said for rolling your own cryptography — control + no integration — which is a really terrible idea.
This doesn't validate your approach since the problem wasn't that a third party you were integrating with messed up your data. I understand why you wanted to build everything in house, but this isn't an example that validates your decision.
1. sales people were pushy dickheads that implied i was wasting their time by re-scheduling their demo due to emergency client issues, when i am their prime audience - an overworked, underpaid, understaffed startup founder.
2. they couldn't articulate how they integrate with my payroll service. it was a bunch of hand waving and "trust us". unfortunately i know how technology works and i'm not going to "trust" anyone unless they have a well defined solution.
had i known i was supposed to give them my administrator login information, it would have been a non-starter anyway.
3. the fact that their business model was basically to take business from existing insurance brokers seemed a little lame to me. why can't i just pay for your services?
2. So - did you get mint.com to tell you how they integrated with your bank(s) ? Did your local bank tell you, for that matter, how they did background searches on their staff ?
3. You clearly don't manage a company with issues like COBRA, insurance, or payroll.
I almost didn't get past #1, but #2 and #3 were non-issues. Why? Because when you manage a business, you have to focus on your core business: So either pay to outsource HR (6K month, thats a salary right there), risk noncompliance with a broker, or go with Zenefits and worry about under-the-bed monsters that do not exist under #2-#3.
for example: i do know the background-check procedures my bank uses on its employees. it's in the fucking brochure they give you when you open a commercial account.
It's kinda balsy, though, to get client's admin ids, and then use that to go after their data.... and then when this is cut off, to complain about it.
Especially given the entitled and, if ADP is being honest, dishonest way they portrayed the events.
Wow. Talk about a disaster waiting to happen.
...From themselves? If someone wants to manage their account through a 3rd party that allegedly uses some non-standard way of accessing ADP then that's a risk they decided to take. ADP should be figuring out a way to give Zenefits (and any other similar companies) more secure access to their platform, not cutting them off.
would the average ADP customer understand thats whats happening?
From the PDF:
Despite having many legitimate ways to integrate with ADP properly, Zenefits chose an unsecure and indirect approach.
> If someone wants to manage their account through a 3rd party that allegedly uses some non-standard way of accessing ADP then that's a risk they decided to take.
From the PDF:
Despite Zenefits serving less than 0.25% of the clients on our system, they had been responsible for up to 25.0% of the total user traffic (in other words, a hundred-fold times ordinary user traffic).
The Zenefits approach was not only putting excessive and unnecessary demand on ADP’s servers, but it was pulling sensitive information, including unmasked Social Security numbers and employee banking information, in a manner that did not comply with ADP’s standards for data security.
It sounds like ADP did what any company, large or small, would do when faced with a third party accessing its systems in an unauthorized and inefficient manner.
Do you really think Zenefits just chose this "lesser" method on a whim? I've never met the team from Zenefits, so I can't say for certain, but if they're not idiots then I think there's a reason why they decided not to use the regular API. Whether that's a requirement of getting their app approved by the ADP Marketplace, or some restriction on the data that they are able to get through the official API - I think that there's something that ADP isn't mentioning.
> It sounds like ADP did what any company, large or small, would do when faced with a third party accessing its systems in an unauthorized and inefficient manner.
As far as unauthorized methods go - you'd patch the hole in your security to prevent them from getting through. Unauthorized methods of accessing your systems shouldn't exist, and blacklisting the domain name of the third-party isn't how you fix a security flaw. For the excessive load, they should just implement rate limiting across their system & return a 429 when someone goes over.
Of course, I really doubt that they were accessing ADP via a real security flaw - they were probably just making the same requests as users are able to, but in an automated fashion. And if that's the case then the term "unauthorized" doesn't apply, because users are clearly authorized to make those requests.
The founder of Zenefits posted here on HN that "APIs == zero errors"[1]. Anybody who has worked with APIs knows this is not the case so you may be overestimating Zenefits' competence.
> Unauthorized methods of accessing your systems shouldn't exist...
Yes, scrapers should not exist.
Practically, I'm not sure that would be much better for Zenefits.
"They gained access to our systems by convincing clients to give them administrative access to our platform."
When ADP's clients giving out administration access[1] is the security hole, that is a reasonable way to patch it. The alternative is for ADP to fire their clients.
[1] I have not seen ADP's TOS, but I would expect giving out the administration login to third party outfits is a violation of it.
It's not ADP's data. It's the employer's data. The employer has decided to use it with Zenefits.
Hell, ADP doesn't even allow the transfer of SSNs from one ADP product to another if it's not absolutely necessary!
[1] http://techcrunch.com/2015/05/06/zenefits-rising-hrs-hottest...
Perhaps Zenefits, having using their hack-around for a while, needs to look at a proper integration? Call ADP's bluff? If ADP is telling the truth that they've never had conversations about service integrations with Zenefits before, it seems like that may be a good place to start.
I think none of our integration projects had an internal cost (labor) of more than about $20k.
Their engineers were really quick to respond to us throughout the process too.
The truth will always reveal itself! /zenefits EE
While they could become a payroll provider themselves, that isn't really their mission. As well, it's not so trivial to write some software "over the weekend" and have a solid payroll system. While payroll companies actually have very little regulation (this is true, and somewhat surprising), it is complex to build a payroll system that can accommodate all the various needs of clients. Just to name a few things to get started: Hourly, salary, pay cycles, 1099, fed/state/local taxes and tax codes and rates, time off tracking, punch in/punch out, check printing and electronic deposit, paper and electronic tax filing, tax payments, garnishments, time off tracking, pre/post-tax deductions, worker's compensation rates, union dues, and the list just goes on from there.
Did ADP just admit they keep SSN and banking information in plain text on their servers???
If you have figured out a way to do something like print a employee's copy of an IRS form like a W-2 or 1099 without having plaintext SSN information involved in the process I would sure be curious to hear about it.
Presumably I already know my SSN, so do not need the W-2 to remind me of it.
But I don't see why it needs to be on things my employer (or their agents) send to me. Sure, SSN is not some highly classified secret, and it is on enough things it does not need to be on that having it on W-2 probably doesn't noticeably cause any extra harm. I'm just curious if it actually needs to be there.
If I'm doing my tax return on paper instead of electronically, and need to physically attach a copy of my W-2, I can fill in the SSN field, just like I filed in the SSN field on the top of the 1040. Having the SSN on the form then, when it goes to the IRS makes sense so that they can match it up to the 1040 if it becomes separated from it accidentally [1].
If I'm doing my tax return electronically, the IRS uses the W-2 information they get from my employer (or its agents) electronically. The paper W-2 is really just to let me know the pay and withholding numbers so I can fill out my returns.
[1] Well, maybe not. It did back in the days when they actually looked at the physical W-2, but now I believe they get an electronic copy even if the taxpayer is not filing electronically, and so I don't think they look at the attached W-2. In fact, I vaguely recall the last time I filed a paper return being told not to attach my W-2, although I'm not certain of that.
I would expact that they need SSN for reporting to the IRS, and bank information for direct deposit. If they are following proper security practices, these will be encrypted on the servers, and get decrypted as needed.
I'm not familiar with what clients can do via the administrative interface, so don't know if it is reasonable to provide access to the decrypted data over that interface.