An anonymous reader writes "Nearly 80 percent of security products fail to perform as intended when first tested and generally require two or more cycles of testing before achieving certification, according to a new ICSA Labs report that details lessons gleaned from testing thousands of security products over 20 years. Across seven product categories core product functionality accounted for 78 percent of initial test failures. For example, an anti-virus product failing to prevent infection and for firewalls or an IPS product not filtering malicious traffic. Rounding out the top three is the startling finding that 44 percent of security products had inherent security problems. Security testing issues range from vulnerabilities that compromise the confidentiality or integrity of the system to random behavior that affects product availability."
You mean after the all the claims they made? After all they said they'd keep us safe from? After how sure they made us feel in their ability? After all the charm, and the cajoling, and the expenses, and the hassle? After all they promised, now that they can't live up to even our most basic expectations, you're telling me that we're the ones at fault?
They can't perform, but now we're the ones who have to change? We're the ones who have to clean all the laundry, and be careful around strangers, and lock up fo
New devices and software may have bugs which affect performance. Patches may be required for correct performance when exposed to unexpected conditions.
Is security software supposed to be automagically immune to human error? Or is this another "Coders aren't employing secure coding practices" piece I've been reading for well over 3 years. "Validate your inputs" "check loops exit under all circumstances" etc etc. Woo. Insightful this ain't.
Mods, please don't mod that uninsightful coment "insightful". Having a defect in a device I've bought has been extremely rare, buying anything from toasters to TV sets to video cards that just don't work is unheard of. Don't talk to me about the "complexity" of writing software, you think you car is simple?
If your software is buggy your company is incompetent. Period. We as customers shoud stop putting up with defective products and beta sofware that's been rolled out as a "finished product." If I find your software doesn't perform, I should get my money back.
People, can we please stop putting up with incompetents' excuses? After a quarter of a century of putting my up with your crap software I'm getting a little tired of it.
Let's imagine you're a car builder capable of building cars with the current expected quality.
Let's now imagine your competition builds and sells defective cars for half your costs. For whatever reason, the buyer will buy the half cost faulty car and then repair it until it finally works, rather than buying your "perfect on release" car.
Let's now imagine your competition builds and sells defective cars for half your costs
So if that would work, why hasn't anyone done it? The answer is simple -- car buyers are smarter than people who buy software. Also, it's a lot easier to patch a program than to recall a defective car.
And cars have warrantees. I'd like to see warrantees on software.
Also, see the AC who responded to your comment, he said a few things I was going to.
Your answer leads to the answer to the post I was answering (which was my intention).
Changing the software quality paradigm isn't a responsibity of the producers, it's the buyers who must start asking for quality and paying for it, as they are who create the market in the first place.
I dunno, let's ask Toyota or Honda why they just can't get people to stop buying Chevys. Oh wait, the car industry doesn't work the way you seem to assume it does.
Here's a quote you might like: I reject your reality, and substitute my own! - Mythbusters
Half of me thinks you're being sarcastic, but the other half is concerned that you think companies actually want to pay for something good, and that PHBs don't impose stupid deadlines to rush projects out of the door because competitors are building the same product.
You want to know which projects are going to be bug-free at realease? Hurd, Duke Nukem: Forever, and the Phantom console.
Your car may be complex, but it has relatively few ways for the user to interact with, and is likely always used in the same environment, and fundamentally the same to most every other car on the road. It's been done. Lots.
This goes doubly for your TV and even more for your toaster.
Are you saying software bugs needn't exist because mechanical and electrical engineering can be done so well? That's asinine.
There's a big difference between software and hardware my friend. The first of which is safety: when a TV or Car blow up or otherwise severely malfunction it is not tolerated and therefore companies that make those products have much different cycles of testing and engineering (Waterfall development cycles). Software on the other hand has much more leniency for most fields since it has the capability of being continually improved and has a tendency to be rushed through development with that in mind (Spiral
http://www.safetyforum.com/fordcruisecontrol/ [safetyforum.com] This is the tip of the iceburg. At least software engineers don't burn people's houses down and kill people with a bug then deny it's their fault.
If your starter goes out a week after buying a new car, there's no safety issue but you're not likely to buy that brand of car again. Any auto manufacturer with shoddy manufacturing and design won't be in business long, unlike software.
I have to applaud your comparison to the car or even the airline sector. If any of those sectors had the same failure rate as the software sector, we would be walking with about 50% less population and an accepted death rate much higher then we do now.
People allow this crap to happen, and still line the pockets of the M$ corporate types. The day we all say no to gas price hikes by banding together and stop buying gas for a full week, like the email sells you to do....then we will see gas prices drop like a
The day we all say no to gas price hikes by banding together and stop buying gas for a full week, like the email sells you to do....then we will see gas prices drop like a hot potato.
Gasoline prices are artificially influenced by the prices of gasoline futures. A little earlier this year gas prices started dropping slightly because of oversupply and decreased demand, then promptly jumped $.25 per gallon in less than a week because it looked like the recession may be ending
Having a defect in a device I've bought has been extremely rare, buying anything from toasters to TV sets to video cards that just don't work is unheard of. Don't talk to me about the "complexity" of writing software, you think you car is simple?
Yes, there are recalls, but I've never had a car I've owned recalled and I doubt many people have had more than one recall in their life. I wasn't just talking about security software and security vulns, but software and bugs in general.
Computer programming has been around since 1843 [wikipedia.org], the gasoline powered automobile [wikipedia.org] wasn't invented until 1806, less than fifty years earlier.
No, but there is a certain level of irony (or at least amusing superposition) when a security product has security vulnerabilities...after all, getting your company hacked because you put in security controls isn't the way one anticipates these things happening. To use a car analogy, it's as if belting your seatbelt led to *more* people dying.
New devices and software may have bugs which affect performance. Patches may be required for correct performance when exposed to unexpected conditions.
I read the article.
Nowhere does it mention that these are new products. Only that they're newly used within any given company.
It also mentions that patching to fix problems is a problem in itself, with 20% of products failing to accept patches properly.
There is no such thing as security. You can become more secure, but never absolutelysecure. Security is a process, not a product. The moment we realize this, most of these problems go away.
Instead of looking for the "silver bullet" in the form of a anti-virus software, you should be using anti-virus in conjunction with Firewalls, the latest patches for your OS, and safe browsing habits. After all, I would bet that 9/10 viruses come in the form of human error rather than the case of a malicious hacker trying to force entry to your system.
No, what he's saying is that a single security solution will <i>never</i> work 100%. You're right, the only magic bullet is to unplug your network cables, but that's not going to happen. That's why you need multiple lines of defense combined with informed usage policies.
This all sounds like security certification speak.
Among the recommendations from the article: "Use certified products. While certification can never eliminate risk, it substantially reduces risk by ensuring that products meet objective, publicly vetted criteria."
This shouldn't be on Slashdot. We all know that the best software tools are FOSS, subject to the most rigourous testing and peer review. "Certified Products" are a black box with a "Trust us" next to a logo for a "Limited Liability Coproration."
The article should be lumped in with the Gartner reports and marketing materials.
FOSS tools are disadvantaged when it comes to certification because certification is expensive, time consuming and resists changes in the project. On the other hand, for-profit vendors are disadvantaged when it comes to security because scrutiny is limited and the motive changes from quality to profitability.
This highlights a point you may very well know already, but allow me to restate it:
People (at least people who program computers) haven't really figured out how to write secure code.
Well, what do I mean by secure code? Code that is 100% secure against a particular well-specified threat, or several of these. I.e. "only users logged in as root on the local console can [...]; users accessing the database through the web interface can't [...].", or "no TCP flow will cause the $OS network stack to crash", or [etc.].
This article is merely the observation that even when people write code that has a security function, they can't magically do better than everybody else.
Also, I'd like to advocate the viewpoint that security is a system property. You can't apt-get install security. Putting a firewall in front of a flaky app (especially a flaky proprietary app) is not going to work well: if you need code to detect whether a packet is evil or not, why don't you put that code in the application, so you don't have three competing vendors waste time trying to be the best flaky-packet-handler for $APP?
Oh well, I guess you can ship sooner. Also, if the original developers of $APP can't get the don't-be-flaky right, we might need something to stand in front.
(I hope this is more coherent than my feeling of well-being would suggest I'm able to make it)
It isn't just the knowing, there is also the bothering. For instance, buffer overflows and SQL injection are some of the most commonly exploited flaws in programs, and the prevention of both is well understood.
The most common source of security problems is poor user interfaces. These can't easily be fixed by third-party products. A ludicrous password policy, for example, which makes people write their passwords on post-it notes because they can't remember them, is a good example. ActiveX allowing untrusted code to run with full privileges with a single button press was another example. UAC and SELinux also suffer from this; the UI is so bad that people often just disable them.
A ludicrous password policy, for example, which makes people write their passwords on post-it notes because they can't remember them, is a good example
If your office door has a physical lock on it, a postit note isn't insecure. My office has no door so I keep passwords written down, in my wallet, disguised as something else. At home it's a list of sites and passwords written down and laying on the computer desk.
I'd like to know why there's the "change your password monthy" rule? It seems to me that a rule l
If your office door has a physical lock on it, a postit note isn't insecure
And the cleaner, being paid minimum wage, won't be tempted to make a couple of years' salary selling the password to an unscrupulous competitor? Depends on your market and how well you vet your staff...
I'd like to know why there's the "change your password monthy" rule?
Cargo cultism. This one actually used to make sense, but was copied by people who didn't understand it. Passwords are stored encrypted. To reduce CPU load, they used to use very simple hashing / encryption algorithms. A month was about as long as you could guarantee that a copied password file would rema
Close but no cigar. You change passwords periodically in order to limit damage. If your password is discovered by someone, then they can only exploit it until the next password change. Guess what...if you keep the same password forever, it can be exploited forever.
Yes, there are many circumstances in which the damage from a compromised password happens immediately after the compromise. But there are times when the damage is ongoing; consider a rival company monitoring the progress of a new product via email
Yeah, I am a bitter vet, and I am so damn happy I got out of that shit world called 'security'.
People were just too dumb, they always wanted to buy products to "make them safe", while they almost never wanted to invest into training, procedures, policies, etc.
So, a certification vendor says certification is necessary, based on statistics produced in-house. Subtext: security product vendors need to buy the services of the certification vendor. It might be true, or it might be bias. Hardly news.
The customer for 'Security Products' is some buyer typically disconnected from the nuts-and-bolts of security!
A bunch of mid-to-upper level people sit in a room and talk about 'security.' They don't understand it, but the like/need the idea of it so they can come off as believable to their customer. Better still the clicky-pointy-GUI and report generation features *really* feed the TPS beast. They talk past each other and pass reports around. Perception! Perception! Perception!
The article paints a negative picture, when in fact the opposite is true: testing works! When we test stuff we find the bugs, fix them and re-test. After a few iterations the tests are passed. What's wrong with that? As someone who's done a *lot* of testing in the past it sounds to me like the process works.
If the testing process didn't find any problems and passed a product on the firsat attempt, I'd be more suspicious of the tests than of the product - not that I'd buy the product, either.
Every security product "fails." It is impossible to prevent all threats. The point of security is to reduce the risk of compromise. There will always be some risk.
If an antivirus product stops now viruses at all, then it's a failure. If it lets some through but stops others, then it is actually a success because it reduces risk.
Security isn't a 'product' that you can bolt on. Security is something that has to be built in from the ground up. A primary function being irrevociable auditing of all activity on the system. How you can design a 'security product' that doesn't accuratly log activity beggers belief. These 'products' sound like the typical management process of covering their arses with certificates.
'Incomplete or inaccurate logging [net-security.org] of who did what and when accounted for 58 percent of initial failures'
... we should point the finger at the criminals that write viruses and otherwise break computers.
They write viruses to "get around" current virus protection. Now if you have a tool that works, and a criminal circumvents it, how does that make the tool faulty? It wasn't faulty when it was written, what makes it faulty now?
Are the software engineers supposed to be able to predict the future? What constitutes a tool that works?
Why don't we hold police responsible for not predicting murders and fireman fires?
As some folks know, a lot of physical security products don't really work, either; they give us a false feeling of safety when in fact there is little or no actual benefit. We've got half of America's cities lit up like Christmas trees at night now, burning who knows how many tons of coal every year to do it, but have all those street lights and backyard security lights really made us safer? Some people got a whole lot richer in that process, though.
Another even more striking example close to home: my city
Most security products are basically after the fact. Does this surprise anyone???
Billion dollar industries have sprung up to address flaws in Windows. Does that surprise anyone?
As the OP says, security products are after the fact solutions. They are intended to band-aid over holes in the product they are ostensibly protecting. They can never fix the actual flaws, nor identify all of the hidden weaknesses.
Well - if you changed your "OpenBSD" to "OpenSource", I could agree with you wholeheartedly. Seriously - BSD looks as good as anything on the market, but I've not found a compelling reason to use BSD instead of the more mainstream Linuxes.
Because you limit your comment to one specific Unix-like, you just come across as a fanboi. Next time, try highlighting the merits of unix-like OS's, then compare how one or another stacks up to each other. You might find a convert - or not. But, at least you won't be
Most security products fail to perform (Score:5, Funny)
I mean you put them under a lot of pressure to perform and chastise them harshly when they fail to meet your expectations.
Perhaps you should mix them a nice drink, use some mood lighting and tell them you love them once in a while. It's not just about you after all.
Reply to This
Re: (Score:3, Funny)
Security devices can't get it up?
Of course not - many security devices require you to get it up before you can even install them.
Re: (Score:3, Interesting)
You mean after the all the claims they made? After all they said they'd keep us safe from? After how sure they made us feel in their ability? After all the charm, and the cajoling, and the expenses, and the hassle? After all they promised, now that they can't live up to even our most basic expectations, you're telling me that we're the ones at fault?
They can't perform, but now we're the ones who have to change? We're the ones who have to clean all the laundry, and be careful around strangers, and lock up fo
Re: (Score:2)
Remove the word "security" from the above sentence and replace with "software", and you'll have a good view of the industry.
This just in! (Score:4, Insightful)
Is security software supposed to be automagically immune to human error? Or is this another "Coders aren't employing secure coding practices" piece I've been reading for well over 3 years. "Validate your inputs" "check loops exit under all circumstances" etc etc. Woo. Insightful this ain't.
Reply to This
Re:This just in! (Score:5, Insightful)
Woo. Insightful this ain't.
Mods, please don't mod that uninsightful coment "insightful". Having a defect in a device I've bought has been extremely rare, buying anything from toasters to TV sets to video cards that just don't work is unheard of. Don't talk to me about the "complexity" of writing software, you think you car is simple?
If your software is buggy your company is incompetent. Period. We as customers shoud stop putting up with defective products and beta sofware that's been rolled out as a "finished product." If I find your software doesn't perform, I should get my money back.
People, can we please stop putting up with incompetents' excuses? After a quarter of a century of putting my up with your crap software I'm getting a little tired of it.
Reply to This
Parent
Re:This just in! (Score:4, Insightful)
you think you car is simple?
Car analogy to the rescue!
Let's imagine you're a car builder capable of building cars with the current expected quality.
Let's now imagine your competition builds and sells defective cars for half your costs. For whatever reason, the buyer will buy the half cost faulty car and then repair it until it finally works, rather than buying your "perfect on release" car.
What do you do?
Reply to This
Parent
Re: (Score:3, Informative)
Let's now imagine your competition builds and sells defective cars for half your costs
So if that would work, why hasn't anyone done it? The answer is simple -- car buyers are smarter than people who buy software. Also, it's a lot easier to patch a program than to recall a defective car.
And cars have warrantees. I'd like to see warrantees on software.
Also, see the AC who responded to your comment, he said a few things I was going to.
Re: (Score:2)
Your answer leads to the answer to the post I was answering (which was my intention).
Changing the software quality paradigm isn't a responsibity of the producers, it's the buyers who must start asking for quality and paying for it, as they are who create the market in the first place.
Re: (Score:2)
I dunno, let's ask Toyota or Honda why they just can't get people to stop buying Chevys. Oh wait, the car industry doesn't work the way you seem to assume it does.
Maybe because Toyotas suck, too [slashdot.org]?
Re: (Score:3, Funny)
Half of me thinks you're being sarcastic, but the other half is concerned that you think companies actually want to pay for something good, and that PHBs don't impose stupid deadlines to rush projects out of the door because competitors are building the same product.
You want to know which projects are going to be bug-free at realease? Hurd, Duke Nukem: Forever, and the Phantom console.
Re:This just in! (Score:5, Insightful)
Your car may be complex, but it has relatively few ways for the user to interact with, and is likely always used in the same environment, and fundamentally the same to most every other car on the road. It's been done. Lots.
This goes doubly for your TV and even more for your toaster.
Are you saying software bugs needn't exist because mechanical and electrical engineering can be done so well? That's asinine.
And last I checked, most cars can still crash.
Reply to This
Parent
Re: (Score:2)
Idiot in, idiot out. PEBSWAC (Steering Wheel)
Re: (Score:2)
And last I checked, most cars can still crash.
Like software, blame the device driver... only with cars it usually is the driver.
Re: (Score:3, Insightful)
Re: (Score:2)
http://www.safetyforum.com/fordcruisecontrol/ [safetyforum.com]
This is the tip of the iceburg. At least software engineers don't burn people's houses down and kill people with a bug then deny it's their fault.
I got news for you: nobody's perfect.
Re: (Score:3, Insightful)
If your starter goes out a week after buying a new car, there's no safety issue but you're not likely to buy that brand of car again. Any auto manufacturer with shoddy manufacturing and design won't be in business long, unlike software.
Re: (Score:2)
You should become an engineer. You sound like you would be a perfect candidate for the job with your quality conscious attitude.
Re: (Score:2)
I'd make a lousy engineer.
Re: (Score:2)
I have to applaud your comparison to the car or even the airline sector. If any of those sectors had the same failure rate as the software sector, we would be walking with about 50% less population and an accepted death rate much higher then we do now.
People allow this crap to happen, and still line the pockets of the M$ corporate types. The day we all say no to gas price hikes by banding together and stop buying gas for a full week, like the email sells you to do....then we will see gas prices drop like a
Re: (Score:2)
I agree with you, except for this:
The day we all say no to gas price hikes by banding together and stop buying gas for a full week, like the email sells you to do....then we will see gas prices drop like a hot potato.
Gasoline prices are artificially influenced by the prices of gasoline futures. A little earlier this year gas prices started dropping slightly because of oversupply and decreased demand, then promptly jumped $.25 per gallon in less than a week because it looked like the recession may be ending
Re: (Score:2)
Having a defect in a device I've bought has been extremely rare, buying anything from toasters to TV sets to video cards that just don't work is unheard of. Don't talk to me about the "complexity" of writing software, you think you car is simple?
I guess you've never heard of factory recalls?
Video cards
http://www.google.com.au/#hl=en&safe=off&q=video+card+factory+recalls&meta=&aq=&oq=&fp=401997eedf2eee64 [google.com.au]
Toasters
http://www.google.com.au/#hl=en&safe=off&q=toaster+factory+recalls [google.com.au]
Re: (Score:2)
Yes, there are recalls, but I've never had a car I've owned recalled and I doubt many people have had more than one recall in their life. I wasn't just talking about security software and security vulns, but software and bugs in general.
Computer programming has been around since 1843 [wikipedia.org], the gasoline powered automobile [wikipedia.org] wasn't invented until 1806, less than fifty years earlier.
Re: (Score:2)
No, but there is a certain level of irony (or at least amusing superposition) when a security product has security vulnerabilities...after all, getting your company hacked because you put in security controls isn't the way one anticipates these things happening. To use a car analogy, it's as if belting your seatbelt led to *more* people dying.
Re: (Score:2)
New devices and software may have bugs which affect performance. Patches may be required for correct performance when exposed to unexpected conditions.
I read the article.
Nowhere does it mention that these are new products. Only that they're newly used within any given company.
It also mentions that patching to fix problems is a problem in itself, with 20% of products failing to accept patches properly.
Re: (Score:3, Funny)
We _cam_ make it bulletproof...
yes we cam?
Security is a process not a product (Score:5, Insightful)
Instead of looking for the "silver bullet" in the form of a anti-virus software, you should be using anti-virus in conjunction with Firewalls, the latest patches for your OS, and safe browsing habits. After all, I would bet that 9/10 viruses come in the form of human error rather than the case of a malicious hacker trying to force entry to your system.
Reply to This
Re: (Score:3, Insightful)
And in related news... (Score:4, Funny)
Reply to This
Talk about devaluing security (Score:3, Insightful)
Reply to This
Confidentiality Integrity Availability. (Score:5, Insightful)
This all sounds like security certification speak.
Among the recommendations from the article: "Use certified products. While certification can never eliminate risk, it substantially reduces risk by ensuring that products meet objective, publicly vetted criteria."
This shouldn't be on Slashdot. We all know that the best software tools are FOSS, subject to the most rigourous testing and peer review. "Certified Products" are a black box with a "Trust us" next to a logo for a "Limited Liability Coproration."
The article should be lumped in with the Gartner reports and marketing materials.
Reply to This
Re: (Score:2)
FOSS tools are disadvantaged when it comes to certification because certification is expensive, time consuming and resists changes in the project. On the other hand, for-profit vendors are disadvantaged when it comes to security because scrutiny is limited and the motive changes from quality to profitability.
We don't know how to do security (Score:3, Insightful)
This highlights a point you may very well know already, but allow me to restate it:
People (at least people who program computers) haven't really figured out how to write secure code.
Well, what do I mean by secure code? Code that is 100% secure against a particular well-specified threat, or several of these. I.e. "only users logged in as root on the local console can [...]; users accessing the database through the web interface can't [...].", or "no TCP flow will cause the $OS network stack to crash", or [etc.].
This article is merely the observation that even when people write code that has a security function, they can't magically do better than everybody else.
Also, I'd like to advocate the viewpoint that security is a system property. You can't apt-get install security. Putting a firewall in front of a flaky app (especially a flaky proprietary app) is not going to work well: if you need code to detect whether a packet is evil or not, why don't you put that code in the application, so you don't have three competing vendors waste time trying to be the best flaky-packet-handler for $APP?
Oh well, I guess you can ship sooner. Also, if the original developers of $APP can't get the don't-be-flaky right, we might need something to stand in front.
(I hope this is more coherent than my feeling of well-being would suggest I'm able to make it)
Reply to This
Re: (Score:3, Insightful)
It isn't just the knowing, there is also the bothering. For instance, buffer overflows and SQL injection are some of the most commonly exploited flaws in programs, and the prevention of both is well understood.
Two things cause security problems. (Score:2)
The most common source of security problems is poor user interfaces. These can't easily be fixed by third-party products. A ludicrous password policy, for example, which makes people write their passwords on post-it notes because they can't remember them, is a good example. ActiveX allowing untrusted code to run with full privileges with a single button press was another example. UAC and SELinux also suffer from this; the UI is so bad that people often just disable them.
The other cause of security pro
Re: (Score:2)
A ludicrous password policy, for example, which makes people write their passwords on post-it notes because they can't remember them, is a good example
If your office door has a physical lock on it, a postit note isn't insecure. My office has no door so I keep passwords written down, in my wallet, disguised as something else. At home it's a list of sites and passwords written down and laying on the computer desk.
I'd like to know why there's the "change your password monthy" rule? It seems to me that a rule l
Re: (Score:3, Informative)
If your office door has a physical lock on it, a postit note isn't insecure
And the cleaner, being paid minimum wage, won't be tempted to make a couple of years' salary selling the password to an unscrupulous competitor? Depends on your market and how well you vet your staff...
I'd like to know why there's the "change your password monthy" rule?
Cargo cultism. This one actually used to make sense, but was copied by people who didn't understand it. Passwords are stored encrypted. To reduce CPU load, they used to use very simple hashing / encryption algorithms. A month was about as long as you could guarantee that a copied password file would rema
Re: (Score:3, Interesting)
Close but no cigar. You change passwords periodically in order to limit damage. If your password is discovered by someone, then they can only exploit it until the next password change. Guess what...if you keep the same password forever, it can be exploited forever.
Yes, there are many circumstances in which the damage from a compromised password happens immediately after the compromise. But there are times when the damage is ongoing; consider a rival company monitoring the progress of a new product via email
Security and Love have something in common (Score:2)
You cannot buy security and you cannot buy love.
Bitter vet syndrome :) (Score:2)
Yeah, I am a bitter vet, and I am so damn happy I got out of that shit world called 'security'.
People were just too dumb, they always wanted to buy products to "make them safe", while they almost never wanted to invest into training, procedures, policies, etc.
Guess they're happy now.
Certification vendor hypes certification (Score:2)
So, a certification vendor says certification is necessary, based on statistics produced in-house. Subtext: security product vendors need to buy the services of the certification vendor. It might be true, or it might be bias. Hardly news.
When Will You Get It Through Your Thick Skull? (Score:2)
The customer for 'Security Products' is some buyer typically disconnected from the nuts-and-bolts of security!
A bunch of mid-to-upper level people sit in a room and talk about 'security.' They don't understand it, but the like/need the idea of it so they can come off as believable to their customer. Better still the clicky-pointy-GUI and report generation features *really* feed the TPS beast. They talk past each other and pass reports around. Perception! Perception! Perception!
The finance industry is th
and that's WHY we test things (Score:3, Insightful)
If the testing process didn't find any problems and passed a product on the firsat attempt, I'd be more suspicious of the tests than of the product - not that I'd buy the product, either.
Reply to This
"fail?" (Score:2)
Every security product "fails." It is impossible to prevent all threats. The point of security is to reduce the risk of compromise. There will always be some risk.
If an antivirus product stops now viruses at all, then it's a failure. If it lets some through but stops others, then it is actually a success because it reduces risk.
security products .. ? (Score:2)
'Incomplete or inaccurate logging [net-security.org] of who did what and when accounted for 58 percent of initial failures'
Maybe... (Score:2)
... we should point the finger at the criminals that write viruses and otherwise break computers.
They write viruses to "get around" current virus protection. Now if you have a tool that works, and a criminal circumvents it, how does that make the tool faulty? It wasn't faulty when it was written, what makes it faulty now?
Are the software engineers supposed to be able to predict the future? What constitutes a tool that works?
Why don't we hold police responsible for not predicting murders and fireman fires?
Th
Many physical security products fail, too (Score:2)
As some folks know, a lot of physical security products don't really work, either; they give us a false feeling of safety when in fact there is little or no actual benefit. We've got half of America's cities lit up like Christmas trees at night now, burning who knows how many tons of coal every year to do it, but have all those street lights and backyard security lights really made us safer? Some people got a whole lot richer in that process, though.
Another even more striking example close to home: my city
Re:well (Score:4, Insightful)
Billion dollar industries have sprung up to address flaws in Windows. Does that surprise anyone?
As the OP says, security products are after the fact solutions. They are intended to band-aid over holes in the product they are ostensibly protecting. They can never fix the actual flaws, nor identify all of the hidden weaknesses.
Reply to This
Parent
Re: (Score:2)
Oh, really [wikipedia.org]? If it's secure enough for these guys [wikipedia.org], it's secure enough for you and me.
Re: (Score:2)
Well - if you changed your "OpenBSD" to "OpenSource", I could agree with you wholeheartedly. Seriously - BSD looks as good as anything on the market, but I've not found a compelling reason to use BSD instead of the more mainstream Linuxes.
Because you limit your comment to one specific Unix-like, you just come across as a fanboi. Next time, try highlighting the merits of unix-like OS's, then compare how one or another stacks up to each other. You might find a convert - or not. But, at least you won't be