Hacker News Reader

Comment by snagglegaggle | Hacker News Reader

Empathy for a self-inflicted problem? Why?

Because they undergo audits that have arbitrary rules, sometimes making it harder or impossible for them to use tools like wireguard.

Yes, I know that is the problem, but that doesn't make it any less self-inflicted.

How is having to conform to an audit performed by an external party as required by regulatory agencies or legislation "self-inflicted"?

They could push back instead of rolling over. You don't usually even need to question the law, just your auditors -- the phrasing of the law is often something that provides adequate provision for reasonable action. If your auditors are unreasonable, fire them.

Regulations (PCI at least) don't prevent you from making your own unaffected COTS VPN server. You may need a FIPS compliant HSM for keying and revocation control but if your a college educated IT professional in an enterprise environment this should be well within your scope.

Of course we all know that's a lie. You could pick 10 random tech executives and none of them would know half the acronyms in this post. Why would they need to? That's why they were paying a vendor. Self inflicted indeed.

PCI is really rather “good” as far as external auditing bodies go, they give broad guidelines on the kind of policies they expect and it’s up to you to implement policies that make sense and they only seem to care about ensuring access controls and heavy amounts of auditing.

HIPPA however...

I do not often hear people describe PCI as "rather good", for what it's worth. "An industry scourge" is a more common sentiment.

You have it backwards. PCI is prescriptive about specific ways you have to implement security, including certain requirements that make very little sense. HIPAA gives broad guidelines and you have flexibility as to how to meet those requirements. You can use a more prescriptive framework such as HITRUST to meet the HIPAA requirements, but you don't have to.

For 99% percentage of all setups involving tunnels like this, key revocation (ala OCSP) is a security risk, not a solution. If your standard blindly requires or encourages this, what it's in effect encouraging is a much more complex and hard to audit set up that can much more easily include human error. As in, I've actually seen that happen. It's just waaaay to easy to have somebody, somewhere screw it up. Worse, you probably don't have full access to every agent in communication network like that, and if only one party messes it up...

So sure, if you're running a public service with all kinds of semi-anonymous users that have no preexisting side-channel, then you may really need all that infrastructure. But guess what? Most problems aren't like that. If you're just setting up a secure channel between a small set of known-in-advance actors then leverage that simplicity! You probably already have some pubkey based channel between them, so you don't need another one!

KISS. You should probably be using a shared token, not an asymmetric key, and definitely no revocation... if your system is simple enough to get away with that.

This is largely false.

He just explained it.

To add on to his points, there are often times corporate policies (You can argue the legitimacy of them or not) that absolutely mandate that you cannot run beta/non-fully released software in production.

One of the last places I worked last ensured that all of our firewall's (and other appliances I'm assuming, they were not my areas though) were an update or two behind (assuming no security vulnerabilities were identified) to ensure stability.

Reply on news.ycombinator.com