This sounds like an insurance problem.

You've got events that occur rarely enough to an individual (company) that it's hard to work out what the best course of action is using the limited data that an individual can gather.

If there were, say, a half dozen major security companies that everyone subscribed to one of, and they each published their statistics showing how many of their customers suffered various kinds of security breaches, this market might look much less broken.

You could potentially get to that state by having some major existing insurance companies offer "digital threat insurance", and require anyone who claims on it to be using the security services provided by one of their vetted providers.

Yes, you'd be building the sort of major corporate bureaucracy that HN hates, but you'd also be properly aligning everyone's incentives, and shifting the responsibility for the Hard Problem of determining who was selling real security software to a smaller number of better-resourced people. Perhaps there's a reason why major corporates are the norm in big, serious markets.

Edit: disclaimer, I'm an armchair theorist and have no skin in the game - perhaps this already exists or there's a good reason why it doesn't work

Seems to me that the core of insurance is actuarial analysis of the potential risks and costs... and I don't think anyone has a good model or good data for when and why security problems occur. For the time being (and perhaps for the rest of time) we need a security crash reporting agency, analogous to a transportation crash reporting agency, e.g. the US NTSB. Getting standard reporting on security breaches might be a good start. I think the National Vulnerability Database [0] is honorable and well-intended, but the reporting there is uneven.

[0] https://nvd.nist.gov/

This. We model death rates somewhat accurately. Health care costs somewhat less so. Macro financial systems somewhat less so. I'd put "assign risk to a moderate sized enterprise's network of data systems" at more complex than all of those.

This solves one incentive problem, but not (in my opinion) the main one. The people responsible for security (i.e. corporate IT departments) are quite often not the same people who would suffer in the event of one (i.e. customers). Therefore, security professionals are mainly incentivized to appear trustworthy.

Actually being trustworthy is certainly the easiest way to do this, at least up to a point. But it tends to push people toward public, visible security measures over private, invisible ones, regardless of their relative effectiveness.

It cuts both ways, too. Even if you do everything right, if you do get hacked that trust is gone and no insurance payout can buy it back. And I'm not sure any customer is going to react well to "Yeah we lost your data, but Goldman Sachs claims it's not our fault".

The incentive problem goes even deeper than that, because customers themselves also don't have a good way to measure the costs of breaches.

If someone company gets hacked, a consumer's gets leaked, and 3 years later that info is used to steal that person's ID, how is that consumer supposed to determine the root cause?

The real problem is that the effects of bad security are very far downstream from the initial problems in space, time, and individuals affected, so proper feedback to those responsible happens very slowly or not at all.

I'd buy infosec insurance, if such a device existed. Premiums go down the more secure your site, the security work itself being a standardized checklist. Forces the snake-oil salesmen out because they'd have to pay out in the event of a breach.

Like you, I have no idea what I'm talking about, but as OP demonstrated you can do everything right and get unlucky, or do nothing right and get lucky. Sounds perfect for some kind of insurance scheme.

> Premiums go down the more secure your site

That shit will bring out the snake-oil men harder than anything. It means those peeps will do all they can to get the auditors to think you are more secure.

Instead, have a requirement of some compliance, with penalties for breaking compliance.

Honus is on the auditors to know what works and what doesn't. Auditors tell you "these are the things you must do to be compliant". Then the oilmen have to sell to people who lose money if they're wrong.

Ticking boxes helps with security, but it tends to be easy to tick the box and yet mitigate much of the actual benefits. When this is cheaper, some companies will chose it, and snake-oil-salesmen will help them do that.

You need some kind of incentive that derives directly from the end goal (less breaches), rather than some derivative (better standards compliance). Auditors certainly have their place, but we need more than them.

edit: Also, you probably meant 'onus' rather than 'honus'.

In some respect, there's been a level of insurance like requirements for some segments. PCI DSS. It's been a decade of so since I had to deal with it, but the requirements were for the most part no nonsense good practices, and instituted a base level of security that was good. Separated DB and application servers. Specific SQL access credentials. Firewalls with pinhole access. Restricted network access for some server roles.

I'm pretty sure this is required because the card industry can't insure against risk accurately without a base level of assurance that your company isn't some fly-by-night IT hellhole. The same concept would likely apply towards any security insurance that was put forth. You would need to certify that certain steps had been taken, and certain future actions would not be taken, for it to be valid.

The problem I had with PCI DSS is that you could check the boxes and if you are never audited, you don't actually have to fix those problems. I worked for a place that ran that way for ~3 years.

Yeah, it is a sort of honor system, but I'm sure if you were hacked, and they see you aren't compliant, it won't go well for you. The fines get steep fairly quick[1][2]. Considering it mentions you might be charged $50-$90 per card even if you are compliant. Although I think those are actually fees for the issuers, I can't imagine they don't have a way to pass then along to merchants.

1: http://www.focusonpci.com/site/index.php/pci-101/pci-noncomp...

2: https://www.pcicomplianceguide.org/pci-faqs-2/#15

This is in theory a good track to start with. However there is one small hole in the theory. Self reporting by security companies on breaches is very tough to impose. We have seen what self regulation/reporting did for the banking industry. If security companies sidestep accurate self reporting on breaches they have no incentive (in fact they might be motivated to let things slide for economic reasons) to create rock solid security solutions because they know there is an insurance company who will absorb the hit.

However if you had an independent entity that rated the security companies' products that might work. Or the insurance company has a division that rates the security products and provided different rates based on which product a company decides to use.

I think a more feasible tactic would be to reverse the responsibility so that vendors that produce easily broken products ends up liable for damages unless they can show that they have done due diligence when it comes to securing the devices that they create. One way to get away from liability would then be to be vetted by a reputable security company.

In theory this sounds good, but I'm afraid in practice, very quickly a market of a few giant "reputable" security companies would emerge, and it will include rather charlatans than people who really know what they are doing. In the end, it will look like rating agencies who were giving AAA left and right in 2008.

However, maybe a system like that would have improved at least the prevalence of the most glaring security holes.

Strictly from an insurance business perspective, there are two major problems with this:

* Netsec events are black swans: it's very, very hard to model how often a security breach will occur. One could checklist all the ways by which we know currently sites are getting hacked, and would still have to pay out, _because hacking exploits things we don't already know_.

* When a hack occurs, it can happen at scale. Unlike eg life insurance, where you have a single payout for hard-to-predict events, the better the hack, the higher the potential for damage, and so the higher the total payout.

These two together means an IT-security-insurance company might do well for a few years, then file for bankruptcy at the first event that hits it, due to inability to pay.

If the incidents were isolated, then I could see this working. In the case of the recent DNS blackout, that took out everyone. Wouldn't that bankrupt the insurance co?

Good insurance companies do not go bankrupt because they measure risk correctly and do not take too much of it on themselves. Essentially it is their job to distribute the risk such that the company remains profitable. A global reaching event would simply be uninsurable.

> It's a few honest people screaming to be heard above the din of snake-oil salesmen...

I think it more likely that it's a few honest, knowledgeable people screaming to be heard above many honest, well-intentioned, but misguided people screaming to be heard above the din of snake oil salesmen.

It's much easier to believe the wrong thing and sell it yourself than it is to be a confidence man. And on the same note, it's much easier to crucify a malicious hacker than it is to ruin the life of a guy who supports his wife and kids who just happened to make the economic call that running everything as root was okay.

To your point on economics, I think the old joke about two guys being chased by a bear applies to the economic mindset. One company is seen tying its shoes (for the sake of the metaphor let's add to the joke that he's otherwise naked), and the other company says slyly "I don't think you're going to outrun that bear." "We don't have to," replies the naked company, "we just have to outrun you."

It's going to be hard to justify the extra 80% effort on the remaining 20% when management and sales only want to go 21% just so they can outlast their competitors.

> And on the same note, it's much easier to crucify a malicious hacker than it is to ruin the life of a guy who supports his wife and kids who just happened to make the economic call that running everything as root was okay.

Makes me wonder who makes the snake oil for the salesmen. I'm trying to say this is a plausible caricature that distracts us from a more complex (and way more interesting) reality.

Well in many cases, the product itself is not snake oil, it's just not as good as it's being sold. I work at a vendor and the product I work with has some unhappy customers who were over-sold and promised the moon when we're actually just a telescope. Being able to see the moon is great, but when it's priced like a moon landing and sold like 40 acres of prime lunar real estate, your telescope looks a little lackluster. And your boss just spent $3m on it, they don't want to hear "now we need to buy all these add-ons, plus we still need a couple more tools to shore up the defenses.

The developers (not me) are just writing the best product they can. The sales guys are trying to get sales. The pricing guys are trying to make it profitable. And no one is talking to anyone else, so the developers don't know what features sales is claiming, sales doesn't know the developers roadmap, and pricing... I don't even know who sets the price.

That's a great point regarding the economics of why IoT manufacturers don't invest all that much on security. Here's another one. It's an externality. Botnet attacks don't harm the IoT manufacturers. They don't even harm the IoT products or their users. They harm completely innocent bystanders like DNS/github.

What possible incentive do IoT manufacturers have to invest money on initiatives that bring no benefits to themselves, or their customers? What possible incentive do users have to follow "proper security protocols", when they can just do something simple/convenient, and if something goes wrong, some random internet website pays the price.

As idiotic as this sounds, the only non-regulatory solution I can think of is for all potential BotNet victims to collectively "bribe" the IoT companies into following proper security protocols.

If ISPs turned off your connection if it was found that something on your network is part of an active attack of a botnet until the problem is cleaned up. Now the 'victim' (I'd not really say victim because they chose the cheapest webcam online) has to figure out (or hire somebody to) clean up their network.

If there are actual consequences for people's computers and IoT devices being 'hacked', they will start to look for ways to avoid the inconvenience in the future. They might start using better passwords, not installing every toolbar under the sun, demand better products (and accountability) from the companies they purchase items from.

tl;dr;

The only way to get some of these problems fixed is to introduce some level of pain, somewhere in the system. I say penalize the consumer who decided to buy the cheapest thing online - turn off their Internet connection when an infected device is found.

This seems the most practical, though I imagine the consumer is likely going change their ISP until they find one that won't. So ISPs have no incentive to do this unless they're regulated.

If customers or ISPs had tools to find out which devices were at fault then it may be more feasible.

It's going to take networks with infected devices being cut away from the Internet like infested tree limbs before things get better.

Externalities are usually solved through pigouvian taxes.

But since we can't really know in advance what product will/won't be secure (or at least it's incredibly difficult in the constantly goalpost moving security industry) the only way I can see this happening is if, say DYN could sue the IoT manufacturers for negligence or something of the like.

Honestly, the general public may benefit from the first few attacks targeting IoT owners.

If your toaster attacks Dyn, that's an indirect failure. But if your lights decide to shut off permanently because some kid thought it would be funny, you're going to throw them away and buy some dumb lightbulbs.

Short of regulation or bribery, I can only hope that we'll see progress after some IoT products are directly attacked instead of repurposed into botnets.

Why would anyone in their right mind attack IoT products directly (ie. disabling/destroying them), when using them as a large botnet is far, far more lucrative?

Well... Perhaps once IoT webcams are used for blackmail - but even that is a much more difficult task than "really big botnet attack really big sites" so the incentive isn't there

The same reason we got ILOVEYOU?

I know profit motivated attacks have eclipsed entertainment motivated ones, but that's partly been about the work required to get a 'strong' exploit going. Mirai used an easier access vector than Morris to get full ownership of target devices, so it wouldn't be hard for one person to copy and abuse.

I don't think this is going to become the norm - messing up a refrigerator isn't a lucrative goal - but I expect that it'll happen occasionally if systems stay this weak.

The best we can get out of direct attacks on IoT are new "security products that protect your IoT devices" in a reactive manner. Windows antivirus all over again.

The safety equipment on vehicles is also an externality but it's mandated because when a car is unsafe it affects other people who aren't the driver. I don't see how IoT is any different. If you don't want to secure your product, then don't build your product and save the rest of us from dealing with the fallout of your laziness.

The principle is no different, but the practice might differ significantly. With vehicle safety there's a reasonably common, agreed upon set of vehicle conditions which can be checked with a inspection; do your brake lights work, tires aren't bald, etc. There is also a framework of regulation (at the product level vehicles have to pass a set of design-level safety tests), as well as policing on actual roads to execute vehicle maintenance checks as needed.

I'm not sure we know what a similar framework would look like with consumer devices. I can see the utility, but I would also worry about regulatory overreach, and giving big brother another point of control to latch onto.

I feel that in the age of technological achievements we currently live in, figuring out a way where we can require a certain level of security on these devices without running afoul of "big brother" syndrome seems well within the realm of possibilities.

It's also worth noting had the IoT companies simply done the baseline level of security of making the user change the password that such regulation wouldn't even be needed, so forgive me if I'm unable to care about their stake in things.

My point is that it's not a technical problem. Some IoT devices have failed their "vehicle safety check". Now who has the authority to take them off the road? Who has the authority to ensure that their poor design isn't even allowed on the road? Do we actually want anyone to hold that authority?

Is there some other way to achieve the same results without formal regulations - to review bad designs and keep them from being sold, and taking bad security designs/implementations off the internet?

Couldn't all those affected by the IoT botnet sue the company fabricating the IoT products?

>You could have no security and just get lucky and never get hacked.

It's been a decade and more since that was even remotely true (if it ever was). Back in 2008 the average survival time of an unpatched internet facing XP box was around 4 minutes [0]. Pwning an unpatched XP box was (very marginally) harder than pwning a system with no security at all. The Morris worm (Edit: which is heavily mentioned in TFA, my bad) [1] got loose in 1998. There's some interesting stuff regarding whether such risks are comparable with things we use insurance to hedge at [2].

[0] https://isc.sans.edu/diary/Survival+Time+on+the+Internet/472...

[1] https://en.m.wikipedia.org/wiki/Morris_worm

[2] http://limn.it/the-morris-worm/

>>Back in 2008 the average survival time of an unpatched internet facing XP box was around 4 minutes [0].

Yep. And that's just the average. It was much, much lower for high-value targets, such as universities. The first thing we did at my Network Security class back in 2006 was to hook up an unpatched XP machine to the Internet. It got pwned in about 30 seconds.

What I don't get about this is how the new system is discovered in the first place, assuming the attacker is not already on the network. Sure, gain fast access, but why would you let the traffic on to the local net to discover the machine (except for examples). I can see a box stuck on a home connection getting pwned quick, but surely a Uni network would be blocking rdp traffic, or external pings, or whatever it was that was being used to find and pwn XP computers so quickly??

Wouldn't multiple attackers have to be effectively flooding the network with pings or service/port access attempts to find a new computer so fast?

At that time? At a university? No. You typically got a public IP address via DHCP and there was no firewall at all. Even today that's still pretty much the case, though a new device is probably assigned a non-routable address until a terms of use agreement is clicked.

They were talking about a XP facing the internet, so without network protections like blocking pings.

Probably just a typing error in your otherwise fine post, but the Morris worm was 1988.

Indeed, good catch.

The solution isn't to have random security consultants come in and kludge up your process and generate useless reports of irrelevant statistics. The solution is to have a red team on staff permanently, to offer bug bounties based on actual access, to install on-server monitoring for outdated packages (like Appcanary, the authors of this piece), to monitor outbound packets for suspicious behaviour (this is currently the hardest part, imo, since, other than detecting major viruses, it's largely domain and network specific), and to have an automated "take the servers off the internet" button for serious 0-days and leaked credentials. Also, always use HTTPS / HSTS lists and two factor authentication.

You'll still get hacked, but you'll be far better off.

"Offer bug bounties based on actual access" why?

Maybe misworded, but actual access is a clear line on the spectrum that starts at reporting a potential DDOS attack on an endpoint to dumping all your users credit cards and passwords. Access to a server isn't necessarily access to a DB, but it's usually serious enough to warrant cash, no matter who you are.

I'm asking: why would you make a bounty conditional on "access" at all? What's the win? A bug is a bug. If it has the potential for access, it's worth the bounty. All a demonstrated access requirement does is encourage strangers to violate the privacy of your customers. It seems like an incredibly reckless idea.

Bad actors are already trying to get that data, no?

Yes, but what does that have to do with the structure of a bounty?

Bounty programs are very noisy. I don't even have a bug bounty program, and have several messages from confused people in my inbox asking about one. The "bugs" they propose are not bugs in my programs---for example, one reports that data can be uploaded to a collaboration system, downloaded, and then executed in a user-provided interpreter---and that this interpreter may surprise the user with its behavior.

Any better ideas of how to structure a bounty to get bugs and not confused users?

Saying something is theoretically possible with automated vulnerability scanners (which have incredibly high type 1 error due to out of date headers due to lazy programmers and misconfigured webservers) and showing that it's actually possible are completely different things. A whitehat proving he can get user access or MITMing data they created as a proof of concept is completely benign. I've yet to hear this as the source of a leak of customer data.

Those sort of information asymmetry problems (in this case, you can't know the quality of the service you're buying until it's far too late) are a textbook case of market failure [1] [2]. You can improve the outcome sometimes with some smart regulation.

But in the security industry there are multiple levels of this problem:

- The end user doesn't generally know how hardened the product he buys is

- The manufacturer is rarely certain how high quality the security auditing/services he is buying

- How much to invest in securing a product is not an easy decision.

I'm of course simplifying a lot here, but you asked for the economics of those problems, and hopefully this was interesting to some.

[1] http://www.sfu.ca/~allen/leffler2.pdf [2]https://www.iei.liu.se/nek/730g83/artiklar/1.328833/AkerlofM...

First off, we need to decentralize centralized services. Second, those decentralized services need to have different types of business models applied to them, long term, for achieving sustainability. Business models are what makes a centralized service centralized, secret and brittle. Change the game theory around infrastructure and you change the speed in which that infrastructure can be hacked. All infrastructure should do is to try to be self-sustaining. Making money off infrastructure is inherently greedy, given it doesn't scale linearly. This is the primary problem today, but I've found most people reject it given their intent is to get "rich" off whatever it is they do.

And of course, even if you get hacked, no consumer buys a camera "how good is the anti-hack feature on this?" and how to even quantify it? Hell people still install viruses because the popup told them to.

That's the problem. Security is either the default, or ignored.

Fire the current crop of security cert vendors and start designing them practically. I may be in the minority, but every {insert security title here} I've ever encountered seems to have an alphabet soup after their name and no hard skills.

Makes me feel bad for the competent security researchers having to share their field with glorified PowerPoint designers.

Sounds like a solution would be to rule out the luck factor and institute dedicated hackers, who aren't ultimately getting paid by the manufacturers.

The first thing that comes to mind is a governmental agency, but then that opens the government/industry watchdog collusion ball of worms.

It's even more slimey in the enterprise space.

I'd like to think that the majority of people involved with the industry in some way have good intentions, but once you start involving, sales, marketing, and certain executives...

Basically some developers need to go to jail for gross negligence.

It wouldn't help. We need to rewrite our entire infrastructure with security as a primary goal. Then we need to find a way to get people to buy it (assuming of course we can even get anyone to pay for it in the first place). Buy one router for 50 bucks or the secure router for 250 ... I don't think we'll get far.

At the end of the day a few people who can't afford super lawyers go to jail, and meanwhile ubercorp producing cheap routers with bad security continue with business as usual.

I think it's deeper than infrastructure.

It doesn't cost more to not write a SQL injection vulnerability. It just takes a programmer who has a basic understanding of internet 101, and who while writing any line of code involving user input will ask himself "how will these assholes use this to fuck with my system". As long as one line of code can take down your whole infrastructure, and unless all devs of anything serious have a minimum competency level, we are doomed to continue the current path, with a major data leak pretty much every week.

So it will probably take a combination of new, safer programming languages, and minimum proficiency levels, enforced with regulations. I don't like it, but I don't know a better solution, and the statu quo is unacceptable.

> It doesn't cost more to not write a SQL injection vulnerability.

It does.

> It just takes a programmer who has a basic understanding of internet 101

Most likely this programmer will cost more than a $10/hr contractor from a third-world country that worked on the software before.

On SQL injections, it doesn't cost more, it just requires to use the correct syntax. Pretty much every database framework offer a syntax to avoid SQL injections. They take a negligible amount of time to type over concatenating a string.

On third world country programmers, first I wish only third world country programmers wrote SQL injections vulnerabilities and other easy to avoid mistakes. Then, if you need to audit your accounts or get some engineers to review the structure of your bridge, you will insist on a good reputation / demonstrable competency. If vulnerabilities will land you in jail, you start looking at quotes from software vendors in a different way.

The point is that it still costs more, on average, to hire the person who understands how to avoid SQL injection by using the right tools/syntax. The person who only understands string concatenation and basic SQL will always be available to hire.

And again you are assuming that these vulnerabilities are introduced by cheap untrained or foreign programmers. Massive silicon valley firms who pay top market rates do the same mistakes. I am sure there is a correlation between pay level and understanding of security but we are very far from a position where if you hire a team of developper, a business can have any confidence that they won't do something dumb like md5 a password, concatenate a string in a SQL qry, rely on user supplied array length in an unmanaged language, not protect themselves against CSRF (I suspect 50% of professional web dev still don't even know what it is!), etc.

> I am sure there is a correlation between pay level and understanding of security

Good, then maybe you can see a path forward to stop arguing the opposite?

Yes, it is possible to pay a lot for a little. Developed country, less developed country, wherever. It remains, nevertheless, relatively less expensive to hire an inexperienced coder than it is to hire an experienced one, who has a greater likelihood of being security-conscious. But no formal mechanism prevents the inexperienced coder from finding work cranking out unreviewed programs.