4 ms·

Think about a company like ADT - they are selling security systems, but the people who really really need security (large clients with large IT budgets) would n

by jmole 2y ago

Think about a company like ADT - they are selling security systems, but the people who really really need security (large clients with large IT budgets) would never buy an ADT system. So like it or not, you're going to be going door to door and helping smaller clients integrate this into their systems. I think the right way to approach this would be to better understand the problems your clients would face when trying to integrate this kind of system, and then figure out how to solve them at scale in a way that you make customer acquisition and onboarding easier in the future. Maybe it's things like creating base docker images for common services or OS pairings that have your stack already integrated. Maybe it's turnkey integrations with existing cloud identity providers or SSO. Maybe it's tailscale integration. In fact tailscale is probably a good model to look at here - no large organization with an existing VPN solution is moving to tailscale, or at least weren't when they first started. But tailscale made a hard thing easy, and that's exactly what you're doing here.

nyrikki 2y ago
Physical security is probably a bad example, when people need physical security they end up calling installers. ADT got where they are by making their installers lives easier, and make it easier to find those installers. I am not the market for the OP. Because I want the ability to change MFA vendors or federate, but the strategies of non-software companies is much different IMHO.
- elevation 2y ago
  What other MFA vendor would you go with? For my own business continuity it might make sense to white-label both yubikeys and an alternative vendor, but Yubico seems to have the best product unless you're wanting to push MFA to user's phones.
  - nyrikki 2y ago
    It is more about vendor and technology mitigation vs selection. Companies fail, projects degrade, like lask week quality can go down. The better question is why would my organization couple their success to you wagon, do you provide them with a way to get their info out in a portable way? But there are many reasons to maintain the ability of your IAM to access multiple IDPs. I do think there is a growing market for products that don't use your private data for their own goals. But coupling a domain controller to a single 2FA provider just doesn't have any value as you have described it, at least for me. I am not the entire market, just one potential user, so take this as feedback and not outright dismissal. Perhaps if you develop the idea more I may be interested in the future.
packetlost 2y ago
Tailscale is a good model for software businesses in general IMO, but they also have another clear advantage over some project like this: they focus on exactly one thing and do it exceptionally well. There's probably a (small) market for out-of-the-box stuff like this, but I'd imagine it has got to be pretty small.
- jmole 2y ago
  So caveat that I am not a small business in need of any of this stuff, but I'll give you an example of the kinds of things that I have struggled with in the past where I think a solution like this could add a lot of value if extended in the right ways: - certificate management amongst a plethora of hosts, both SSL/web certificates for external use, and management and installation of self-signed "root" certs for validating internal applications and services - keymastering server: an appliance that acts as a genuine root of trust for an organization, using a Yubico HSM for key storage, but providing middleware & admin controls to manage issuance and distribution of intermediate certificates - AD/LDAP/SSO/etc user management, key issuance, etc. If you have a small team and you don't need global redundancy for these functions across a large fleet, then it makes a lot of sense IMO to shell out $5-10k for a set it and forget it security appliance that makes certificate/key management simple and easy. I think the biggest challenge is that it's hard to build trust as a startup without open-sourcing your stack, but that makes it a lot harder to get buy-in for an appliance model unless you have some creative dual-licensing ideas. But "your keys/certs are stored securely on your hardware in the room next door" is a compelling value proposition & probably a much easier pill to swallow for certain companies than a cloud HSM or other solutions which sorta boil down to "trust me bro".
  - packetlost 2y ago
    Sure, so focus on being a local certificate authority using hardware backed roots. I can see that being valuable, but you'd be competing against companies like Smallstep.
  - elevation 2y ago
    > using a Yubico HSM for key storage, but providing middleware & admin controls > a compelling value proposition I completely agree; I'd originally drawn up a design for an offline root CA, then an box with a separate server for an intermediate CA with HSM for intermediate keys, a second, dedicated Secure NTP server (possibly hardware based) so that certificate expiration times could be kept short. While all that is easy enough to prototype, the complexity of hardware distribution is better left to a later point in the roadmap.
formerly_proven 2y ago
Physical security like ADT is so yucky to be honest. It violates _all_ the principles we use in IT security. The vendors are super secretive about their specifications and even basic aspects are usually impossible to figure out / considered a business secret. Like, I was looking for an RFID entry system for a customer. Some of these are advertised as using DES/AES security (implied to be some version of DESfire). Most aren't. Try figuring out if they actually use DESfire and if the handshake is tunneled to the door controller (placed in a secure area) or the card reader (placed in the vulnerable, insecure area) has the keys and is just sending the UID to the controller. Nobody will answer this question. (Presumably because these secure systems are all actually UID-only on the backend so trivial to bypass if you learn a valid backend UID). And even then, you're like "Okay, this sounds interesting. I wanna buy it." - "Oh, you can't. We don't sell these. You need a system integrator / installer." And then you go to one of these and it's super obvious they have essentially no clue how any of the stuff they're system-integrating works, but of course they won't give you admin access to the system they wanna install. "How do I configure this?" - "You don't. Only we do. Using a proprietary software." - "Where's the system manual for this?" - "We have it, we can't and won't give it to you." I mean a lot of stuff works like this, usually with incompetent middle-men fucking up products which aren't all that bad (another most popular example would be HVAC and heat pumps, especially ASHPs) and manufacturers trying to make a SaaS kind of play with hardware you bought. But for security it feels especially egregious. How do you know the installer doesn't have a master key? Well, they usually do. How do you know the ACLs are set up correctly? Trust me bro. And so on.
- razodactyl 2y ago
  Reminds me of a time I had a heat pump water system installed with clearly labeled warnings on the outlets that the covers needed to be removed or requirements that the fans be sheltered. None of this was done. It was out in the sun (laminate on control panel fused to the screen), air intake was factory sealed (system failed after a while) and it was left in the rain after an installer came to remove the covers (air intake / exhaust are top facing). I could have easily solved the issues myself but didn't want to give them the option of pinning liability on the client.

by jmole 2y ago

nyrikki 2y ago

Physical security is probably a bad example, when people need physical security they end up calling installers. ADT got where they are by making their installers lives easier, and make it easier to find those installers. I am not the market for the OP. Because I want the ability to change MFA vendors or federate, but the strategies of non-software companies is much different IMHO.

elevation 2y ago
What other MFA vendor would you go with? For my own business continuity it might make sense to white-label both yubikeys and an alternative vendor, but Yubico seems to have the best product unless you're wanting to push MFA to user's phones.
- nyrikki 2y ago
  It is more about vendor and technology mitigation vs selection. Companies fail, projects degrade, like lask week quality can go down. The better question is why would my organization couple their success to you wagon, do you provide them with a way to get their info out in a portable way? But there are many reasons to maintain the ability of your IAM to access multiple IDPs. I do think there is a growing market for products that don't use your private data for their own goals. But coupling a domain controller to a single 2FA provider just doesn't have any value as you have described it, at least for me. I am not the entire market, just one potential user, so take this as feedback and not outright dismissal. Perhaps if you develop the idea more I may be interested in the future.

packetlost 2y ago

Tailscale is a good model for software businesses in general IMO, but they also have another clear advantage over some project like this: they focus on exactly one thing and do it exceptionally well. There's probably a (small) market for out-of-the-box stuff like this, but I'd imagine it has got to be pretty small.

jmole 2y ago
So caveat that I am not a small business in need of any of this stuff, but I'll give you an example of the kinds of things that I have struggled with in the past where I think a solution like this could add a lot of value if extended in the right ways: - certificate management amongst a plethora of hosts, both SSL/web certificates for external use, and management and installation of self-signed "root" certs for validating internal applications and services - keymastering server: an appliance that acts as a genuine root of trust for an organization, using a Yubico HSM for key storage, but providing middleware & admin controls to manage issuance and distribution of intermediate certificates - AD/LDAP/SSO/etc user management, key issuance, etc. If you have a small team and you don't need global redundancy for these functions across a large fleet, then it makes a lot of sense IMO to shell out $5-10k for a set it and forget it security appliance that makes certificate/key management simple and easy. I think the biggest challenge is that it's hard to build trust as a startup without open-sourcing your stack, but that makes it a lot harder to get buy-in for an appliance model unless you have some creative dual-licensing ideas. But "your keys/certs are stored securely on your hardware in the room next door" is a compelling value proposition & probably a much easier pill to swallow for certain companies than a cloud HSM or other solutions which sorta boil down to "trust me bro".
- packetlost 2y ago
  Sure, so focus on being a local certificate authority using hardware backed roots. I can see that being valuable, but you'd be competing against companies like Smallstep.
- elevation 2y ago
  > using a Yubico HSM for key storage, but providing middleware & admin controls > a compelling value proposition I completely agree; I'd originally drawn up a design for an offline root CA, then an box with a separate server for an intermediate CA with HSM for intermediate keys, a second, dedicated Secure NTP server (possibly hardware based) so that certificate expiration times could be kept short. While all that is easy enough to prototype, the complexity of hardware distribution is better left to a later point in the roadmap.

formerly_proven 2y ago

Physical security like ADT is so yucky to be honest. It violates _all_ the principles we use in IT security. The vendors are super secretive about their specifications and even basic aspects are usually impossible to figure out / considered a business secret. Like, I was looking for an RFID entry system for a customer. Some of these are advertised as using DES/AES security (implied to be some version of DESfire). Most aren't. Try figuring out if they actually use DESfire and if the handshake is tunneled to the door controller (placed in a secure area) or the card reader (placed in the vulnerable, insecure area) has the keys and is just sending the UID to the controller. Nobody will answer this question. (Presumably because these secure systems are all actually UID-only on the backend so trivial to bypass if you learn a valid backend UID). And even then, you're like "Okay, this sounds interesting. I wanna buy it." - "Oh, you can't. We don't sell these. You need a system integrator / installer." And then you go to one of these and it's super obvious they have essentially no clue how any of the stuff they're system-integrating works, but of course they won't give you admin access to the system they wanna install. "How do I configure this?" - "You don't. Only we do. Using a proprietary software." - "Where's the system manual for this?" - "We have it, we can't and won't give it to you." I mean a lot of stuff works like this, usually with incompetent middle-men fucking up products which aren't all that bad (another most popular example would be HVAC and heat pumps, especially ASHPs) and manufacturers trying to make a SaaS kind of play with hardware you bought. But for security it feels especially egregious. How do you know the installer doesn't have a master key? Well, they usually do. How do you know the ACLs are set up correctly? Trust me bro. And so on.

razodactyl 2y ago
Reminds me of a time I had a heat pump water system installed with clearly labeled warnings on the outlets that the covers needed to be removed or requirements that the fans be sheltered. None of this was done. It was out in the sun (laminate on control panel fused to the screen), air intake was factory sealed (system failed after a while) and it was left in the rain after an installer came to remove the covers (air intake / exhaust are top facing). I could have easily solved the issues myself but didn't want to give them the option of pinning liability on the client.