26% of Companies Ignore Security Bugs Because They Don't Have the Time to Fix Them (bleepingcomputer.com) 90
Catalin Cimpanu, writing for BleepingComputer: A survey compiled last month at the RSA security conference reveals that most companies are still behind with proper security practices, and some of them even intentionally ignore security flaws for various reasons ranging from lack of time to lack of know-how. The survey, which compiled answers from 155 security professionals from the companies present at the RSA conference, revealed that only 47% of organizations patch vulnerabilities as soon as they are known. Most worrisome is that some companies wait quite some time before applying patches, exposing their IT infrastructure to attacks. More precisely, 16% wait for one month, while 8% said they only apply patches once or twice a year.
It's not time, it's money... (Score:5, Insightful)
It's not that I don't have enough time, I do.
It's that the powers at be only want to spend time on something if a client pays for it.
Re: (Score:3)
You work for free?
I have some bridges you might be interested in.
Re: (Score:1)
It's that the powers at be only want to spend time on something if a client pays for it.
Such situations tend to create regulation.
Re: (Score:3)
If you're a plumber and you hear the house two doors down, whose pipes you installed 4 years ago during the construction of the house, has a leak. You aren't going to go and fix it for free, are you?
I don't know what kind of regulation could facilitate good business and secure products. The more secure you make something, usually the more it will cost the client (even with security-first orientated programming).
Re:It's not time, it's money... (Score:4, Funny)
No, but I have some damn fine hearing..!
Re: It's not time, it's money... (Score:3)
Oh, that's easy.
1. All commercial software must be classed as fit for purpose within specified design parameters.
2. All commercial software must have a warranty of 5 years where all defects will be fixed at vendor's expense.
3. Vendors of software that violates CERT's secure coding rules, implements back doors or uses encryption algorithms broken at time of release shall be liable for losses due to security flaws.
4. Vendors of mission-critical software must, on demand, provide proof of formal methods, extrem
Re: (Score:2)
Which should mean that there is complicated software out there without security flaws, and I don't believe that.
Re:It's not time, it's money... (Score:5, Insightful)
well, it IS time. but time IS money. so, yeah, kinda.
Pinheads that only how how to count beans and don't understand the problem are asking each other "Is it important? How much does it cost? What's the return on investment?"
They don't see the risk or the cost of losing on the risk. They only see the cost of the fix, and that looks like a very poor ROI, and it gets shot down, or continuously delayed.
Re: (Score:1)
I hate to think of how many times I've had a conversation something like this:
Manager: Give me a gantt chart of the tasks to get this project done in three months Me: The tasks to get it done will take six months Manager: No, it's easy. Divide the number of tasks into three months and give each task that much time Me: [facepalm]
No lies detected.
Re:It's not time, it's money... (Score:5, Interesting)
Honest question though: What IS the cost? Equifax suffered a breach of pretty much the most sensitive possible data you can have leaked, and if this article [pymnts.com] is correct, the total cost is approaching about $500 million. Had there been no data breach or had the data breach never been made public or had there been no political will to prosecute the company then the cost would have been practically nothing.
Imagine a sort of reverse lottery. If you don't buy a ticket, there is a small chance (and nobody can tell you the exact likelihood) that your reputation will be publicly tarnished and you will be fined millions of dollars. If you buy a ticket, your chance drops drastically (but is never really zero). But the ticket costs thousands of dollars. Would you buy the ticket? What if the ticket is tens of thousands of dollars? What if it's hundreds of thousands of dollars? Is there a point where you will simply refuse to buy the ticket and accept the risk?
I'm not saying these companies are making the right choice. I'm saying that from a purely practical standpoint I understand why someone might make the choice not to invest heavily into fixing security bugs. It's not the same choice I would make, but I seem to be more risk-averse than the average person judging by the choices I have seen people around me make. Still, if you don't understand why someone would make a decision, how do you ever expect to convince them to make a different decision?
Re: (Score:2)
... Imagine a sort of reverse lottery. If you don't buy a ticket, there is a small chance (and nobody can tell you the exact likelihood) that your reputation will be publicly tarnished and you will be fined millions of dollars. If you buy a ticket, your chance drops drastically (but is never really zero). But the ticket costs thousands of dollars. Would you buy the ticket? ...
What if the "tickets" had a small but definate chance of being contaminated, and making you very sick? The patches to computer systems have been getting more and more dangerous to people's businesses, to the point where they must consider if the risk from the patch is more than the risk from the criminal intruders. This is the real reason people are waiting, to see what happens to the first to try. All else is excuses to stop you from pestering them.
Re: (Score:2)
The real issue with the reverse lottery is not whether the company would stomach the risk. It's that to the individual manager the risk is very low, while the worst consequence is that he's fired. It's the same reason many managers like to kick the can down the road, it's not because it's good for the business but his performance looks good one more quarter. They're seeing most the upside when it goes well and very little of the downside when things go catastrophically bad.
Re: (Score:2)
What IS the cost?
You can't consider the cost in isolation. You can only consider the risk. If you only consider cost then nothing would ever advance as you don't take into account the likelihood of the high-cost event hitting you.
Risk is fundamentally the likelihood of something happening and the consequence of it happening. I could die from getting hit by an asteroid. It's unlikely so I live with the risk rather than building an asteroid proof hat.
Re: (Score:2)
That already exists, and it's called "medical insurance" ;)
Re: (Score:3)
This.
And this is limited isn't limited to contracting situations (where you typically hear the word "client"). I have seen this in companies that sell products on the open market, to whole industries. The company takes the approach that development schedules are dictated by what features customers say they want. Since the customer doesn't know the security problem exists they can't say "I want this fixed". It is therefore not a priority.
Re: (Score:1)
That's also been my point for quite some time. Almost all the time, the last thing on the client's list of requirements is security. Especially if the client is a consumer...
Hence the need to legislate harshly...
Re: (Score:1)
Well isn't that the problem: if your company invests in better security measures, charges more and nothing ever happens, then you lose to your competitor that ignored security completely. It's a dice roll, but the big investors can hedge by investing in multiple dice rolls. Most likely by the time the big security breach happens, the only companies left are the ones who didn't invest in security (their competitors either left the space or stopped investing in security to try to compete with the lower prices
Re: (Score:1)
I second this, every couple weeks I try to underline the fact that our bug graph is going up and we need more people (three man team) yet still find the planning filled to the rim with new features to develop. Occasionally some high-profile customer brings down the hammer on our CEO regarding all the problems that still exist, that seems to help for a couple days.
Re: (Score:1)
If the PHB's do give it any thought, they may conclude a 15% chance of getting hacked into bankruptcy is worth the risk of growing now by shaving off security measures. If the company croaks, they blame it on the techies (they don't put corner-cutting orders in writing), and move on to a different gig. Rinse, repeat.
Re: (Score:2)
It's true, the security must be treated as a feature, and the customer must be told that security is a feature that they want (sometimes it seems this isn't true). However the fault often lies in sales and marketing, where a deadline for product delivery is set before product design and development even begins. Security often gets short-shrift at the end when a project is running late. That's why your security subject matter expert must always be a bastard willing to shout in meetings. The security team
. . . or they spent the money on something else. . (Score:2)
. . . I run a Secure Code Analysis team. I am **CONSTANTLY** bombarded with "well, this is legacy code, there's no budget left for security. . . ."
Dude. One of the requirements in the contract was to comply with the appropriate regulations and best practices. Which, despite my team bugging you for literally YEARS, and pointing out where the contract specifically requires code reviews. . . .I get told "when did this requirement come in" and "we don't have the money for that." But apparently they had th
patch vulnerabilities as soon as they are known (Score:1)
Yea, no shit. You don't just apply a vendor supplied patch to prod and hope it doesn't break anything.
Re: (Score:3)
Yeah, that didn't exactly work out well for the early adopters of the Spectre and Meltdown fixes. Not only were they initially buggy as well, but they didn't even fix all of the security flaws.
Like it or not, it's usually best to wait a day or two for someone else to be the guinea pig for security patches before putting them into Production, unless the issue is actively being exploited by a virus or a worm.
Re: (Score:1)
Then 26% should be sued (Score:4)
Re: (Score:3, Insightful)
Were it only so simple, but a few things tend to push security down the priority list.
1) Lack of perceived value. If it takes company A 100 man hours to implement a product with proper security, and company B 80 man hours do to the same thing but with poorer security practices, then most clients and consumers will choose company B (assuming no other factors at play) because of the reduced cost and the fact that good secure implementations are not easy to ascertain at a glance.
2) Lack of perceived consequenc
Re: (Score:2)
Most non-technical people do not have even the most basic grasp of the issues, and cannot be expected to. They assume that software is required to be "goods of merchandisable quality" like anything else, and believe bugs crawl into software the same way cockroaches get in the kitchen. They s
Re: (Score:2)
Risk Management. . . (Score:2)
. . . anyone who has studied for a CISSP or SANS GIAC Cert knows about risk management.
1. How likely is the bug to be exploited (x times a year)
2. How much damage will the bug cost ? (y dollars per attack")
. . . and THEN: how much will it cost to fix the bug. ( call it "z": recoding, testing, review. distribution of fix)
Then you do the math: If z is less than x times y, it makes sense to fix the bug. If z is more than x times y, and especially much more, you accept the risk. And you revisit the questio
Re: (Score:2)
It's not my shit to fix. I didn't create it. I bought a [software] tool, I paid for it, I've been using it for some time.
It was always broken, but it took this much time for someone to notice the bug. Now there's a fix.
I don't have time to stop manufacturing white tube socks in order to upgrade the e-mail client that I purchased years ago.
So sorry.
You have three options.
The first is the current plan -- I get to it when I get to it, and you don't complain.
The second is that you have the creator of the sof
Re: Then 26% should be sued (Score:3)
If you bought a car and the car is then recalled due to a propensity for the brakes to fail, you don't get to claim in court that the pedestrian you ran into was just unlucky but that it wasn't your shit to fix.
That excuse doesn't fly. If the product is dangerously defective and you know that it is, you are liable.
Re: (Score:2)
I won't allow you to equate the privacy of names and phone numbers with instant death.
Re: (Score:2)
From a software standpoint, a failure to validate inputs and a failure to validate code against a specification is independent of what the code does.
In ISO 9000 training, we were taught that we should consider anything that could cost $1m or more if things went wrong to be equivalent to killing someone. But, hey, what does NASA know about failure not being an option?
Re: (Score:2)
Good old little Bobby Tables. . . [xkcd.com]
Re: (Score:2)
If your solution is writing quality software, that's a non-starter. It might be possible to write really good software. But it'd be text based. No fonts. No images. Very few capabilities. Few or no configuration options. And it'd cost.
Trust me, the world is not yet ready for a life without cat videos. Maybe after another decade of pain, that'll look like an OK idea. But for the time being we're going to continue to hold things together with duct tape and charge forth into a glorious (if wildly ins
Re: Then 26% should be sued (Score:2)
In part, software vendors renting rather than selling products are responsible, along with a refusal to offer a warranty.
I'd suggest placing stiff penalties on failing to follow established practices, and jail sentences for failing to fix in a timely manner or responsibly upgrade in a timely manner.
Making it a criminal offence with a ten year fixed tarrif should liven things up.
Re: (Score:2)
Should we give you a secure coding quiz?
Because that worked so well (Score:2)
Like Windows XP in China. (Score:1)
Nobody should (Score:1)
Nobody with any experience installs a patch immediately when its released if they aren't forced to. It only takes one time borking your entire network/domain by being the unwitting beta tester to learn that lesson.
Re: (Score:2)
even if they were to hire penetration testing services they were sure the pen-testers wouldn’t expose any new risks or flaws. The sheer ignorance of such statement somewhat explains why some respondents admitted to not having time to apply security patches
We hired a pentester and they didn't expose any flaws, we already knew about all of them. Phishing email, macro or exploit to powershell to downloaded binary to credential theft v
In related news (Score:5, Informative)
Re: (Score:2)
depth of defense (Score:2)
Correct security is about depth of defense. If you -have- to patch immediately every time then you've already failed.
Take your time. Do it right. If you understand your security posture and have designed it well, patching once or twice a year may well be sufficient.
no consequences (Score:3, Insightful)
it's because of the lack of consequences, not because of time.... they would take the time to fix the issues if there would be appropriate consequences if they don't
Purely from academic interest ... (Score:2)
Purely from academic interest and in the cause of like research and al that, which 26%?
They are lying. (Score:2)
Re: (Score:2)
Ah, another person who hasn't yet read Brooks' "Mythical Man-Month". There's a chapter examining exactly what happens when you hire more qualified people because you're not going to make the deadline.
Blue Screens (Score:1)
Most organizations don't have resources to hold a fall back copy of their production server(s)
Re: (Score:2)
Most (read: all) organisations I've worked for have two sets of production servers. Prod and DR.
Software updates and patches only happen to one at a time, until it has been proven good. If there's a failure, there's almost no down-time as the server roles are switched.
Or.. (Score:2)
..don't have the technical competence
Security is hard
Security only becomes a critical issue (Score:2)
when your Corporate name is being dragged through the mud, the Litigation Monster makes an appearance, your share-holders are getting out the torches and pitch forks and management is frantically looking through the list to see which Junior Developer they can pin the blame on for the ' bug ' in the code.
THAT is the only time companies take security seriously because, let's be honest, there are otherwise no consequences for being the Corporate equivalent of an incompetent fuck up. A slap on the wrist, a med