,
10 tweets,
3 min read
Read on Twitter
All moralizing aside, refusing to ship your analytical data to a third party service is an *incredibly* costly choice. You have a limited # of engineering cycles, and you want to spend as many of those as possible on moving the product forward, on creating core business value.
Everyone underestimates how much engineering muscle it will take to run an internal data warehouse or analytics engine. I'm not talking about *great* tooling; I mean completely mediocre tooling with little if any innovation.
First of all, you can't recruit great engineers to work on your internal walled garden. (If you somehow manage to do so, you will be wasting them, and they know it.) Second, it will constantly split your focus and cause both products (core and analytics) to suffer.
How much better could your core product be if you turned those world-class engineers loose on it instead of making them clean up behind it? Managers do a terrible job of accounting for people-hours costs and focus costs, across the board. Terrible.
The bluster around "but we have PII/PHI" is mostly an excuse. It didn't used to be, but today it is. Plenty of companies manage to do this. Yours isn't special. There's certifications, there are alternate best practices, there is a community of secure companies doing this.
A little bit of hygiene and post-hoc validation goes a looooong way here. You do not NEED (or want) PII/PHI data in your operational data stream, period. Run a script on both sides to check for it, shut it down if you see any, use a hash to run computations on the shape of it.
Honeycomb has a product called Secure Tenancy that fulfills the (sometimes arbitrary) demands of security teams that a service not be able to decrypt data, or never receive your unencrypted OR encrypted data. docs.honeycomb.io/authentication… It works great. We never even see your keys.
Yes, we've had security audits and pen tests. Yes, we have gov tech and health care customers. Yes, any security team that is genuinely trying to help you solve the problem should allow this solution.
I agree, you shouldn't be shipping PII/PHI off to other services willy nilly. _Obviously_.
But a whole shitload of baby gets thrown out with this weak tea bathwater every goddamn day.
But a whole shitload of baby gets thrown out with this weak tea bathwater every goddamn day.
Anyhow: I have a series of three blog posts in the works on how to work with your security teams to choose a provider and roll it out internally. It comes from three security professionals: @attacus_au, @eqe and @georgechamales, and it will get published this week. Stay tuned.
