The Security Industry Is Failing Miserably At Fixing Underlying Dangers
cgriffin21 writes: The security industry is adding layers of defensive technologies to protect systems rather than addressing the most substantial, underlying problems that sustain a sprawling cybercrime syndicate, according to an industry luminary who painted a bleak picture of the future of information security at a conference of hundreds of incident responders in Boston Tuesday. Eugene Spafford, a noted computer security expert and professor of computer science at Purdue University, said software makers continue to churn out products riddled with vulnerabilities, creating an incessant patching cycle for IT administrators that siphons resources from more critical areas.
Nothing to see here, move along.
It seems like his solution is: Simply don't release code that has bugs in it. Which is kind of like saying that the airline industry would be so much more efficient if we could just get rid of wind resistance.
I read the internet for the articles.
Anybody may write programs, and it looks like there's hardly a nitwit who doesn't. I've said it before, I'll say it again: The stream of crap won't cede unless the software industry is made liable for software defects.
The ONLY winners in that scenario would be the lawyers.
Faster! Faster! Faster would be better!
"We have no consequences for sloppy design and we don't hold organizations accountable for bad things."
Clearly Eugene Spafford must be put in charge immediately, since none of the rest of us have figured any of this out!
SJW's don't eliminate discrimination. They just expropriate it for themselves.
That would end the stream of crap in commercial software. Non-commercial software, on the other hand, would not cease to be produced the very second such a law was made.
"When information is power, privacy is freedom" - Jah-Wren Ryel
But there sure is a lot of money in selling threat paranoia.
Plus software vendors are apparently immune from product liability, so they never bear any costs for defects that lead to poor security or for implementing security poorly. If they had liability for this I think you'd see a lot fewer security defects, but probably a lot fewer features as well.
how will you find time to do it twice?
Happiness in intelligent people is the rarest thing I know.
Ernest Hemingway
... substantial, underlying problems that sustain a sprawling cybercrime syndicate, according to an industry luminary who painted a bleak picture of the future of information security at a conference of hundreds of incident responders in Boston Tuesday.
I do have a to agree in that the current development style/strategy (agile development) is less geared towards solid development and more on features and getting stuff out there. I think the article is just saying that they should do less of pushing out features and new things and more on good programming/fix known bugs. Of course putting out a bugless program is near impossible, but there's a difference in better prevention versus better clean-up.
please... let me sleep... a little more... yay, no longer annonmyous coward.
its a n underrated point - why don't software engineers have to make products as reliable and good as more expensive engineering projects... and I think the clue in is that question.
Why can't a software engineer make something that is as reliable as a bridge? Because a bridge costs a flipping fortune and can't really be reworked after implementation, so there's a huge incentive to get the entire team together to get it right. And that means the people who really make the bridge are the architects and project managers. In software terms, we have few architects and they're usually crap ex-developers who think they know it all, and project managers who are incompetents who think it was a job they can hide their lack of skill in. Meanwhile you have a load of developers who think they are the only ones who can do the job.
A really good software project would require a technical architect who really understood what was happening and how things worked, and a project manager who understood timescales based on experience and managing the project deliveries and organisation.
It would also require a project based on old technologies - no-one really has time to get to grips with something like 'real' engineers have to do because the platform they stand on gets whipped out from under them all the damn time - which is also a problem as the idiots who don't know a thing use this as an excuse to hide their lack of talent too (how many times have you heard that someone wants to rewrite in cool new technology almost for the sake of it - you can guarantee its because they can't hack doing the boring work maintaining or improving the old stuff, a lack of skill they'd still have if they did get to rewrite - no rewrite ever is any good, its almost always an even worse PoS).
So all in all, there's a huge lack of professionalism in software caused by a lot of factors but I think the biggest one is the real lack of earned experience. We don't allow the good stuff to be built upon, we throw it away and start again with something else. We throw the good staff away and say they're not keeping up with technology. We hire kids because they have some buzzword on their CV.
Anyway, we don't hold software engineers to the same high standards because we refuse to accept old, working stuff. We only want cheap new shiny crap. Its no wonder the software world has turned out like it has.
It would cease to be produced the moment the lawyers put the squeeze on the distribution points and organizations hosting the non-commercial software.
Underlying dangers: the user?
What we should do is research safe alternatives for languages (http://www.rust-lang.org/), more sandboxing of who can access what (SELinux, AppArmor), and better and simpler libraries (LibreSSL). No plugin Auto-run for untrusted sites.
Antivirus is cool and all, but its not as good as fixing the bugs. Unfortunately it is more profitable.
I used to think that Open Source development methods would lead to convergence. Software could only get better, as people maintained it and continued to make it better.
Unfortunately, there is always the ego factor. People want THEIR stuff in there and that older idiot's code needs to be snipped out and replaced. Far be it for anybody to learn to communicate through their code and build something coherent for other people to build on. It happens, and some of the 'leading' projects have grown better through an evolutionary process. But it's the exception.
> an opinion
An opinion doesn't require a solution, especially since it doesn't provide any facts to characterize.
There's no evidence that the security industry has been failing by adopting tools and methods that quite a few people use. The fact that there are few critical systems (that I use daily) which use username/password as the sole security credentials is a huge win over my experiences in '00. I think the security industry has pushed hard and made a serious dent.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Anti-virus is not a solution to the real problem!? Whaat? How can this be?
Cite your sources.
Which has more power: the hammer, or the anvil?
Working in this industry at several giant companies, the view is simple - the company works for the stockholders, the stockholders demand ever higher returns, and NOTHING the company does is nearly as important as increasing the short term stock price. So what money is spent on R&D will be spent chasing new "shiny" features and the absolute bare minimum level of security and bug fixes required to "continue leveraging the brand". In the mean time, the business will focus on increasing the productivity of its remaining workforce, and continue to look for new ways to innovate through outsourcing, off-shoring, right sizing, acquisitions, virtual workforces, and anything else that looks good on paper for short term gains while not requiring hiring new FTE (Full Time Engineers), at least domestically.
Yes there are bad products, an increasing quantity of bad products. And an increasing quantity of things to fix more than once. And an increasing number of exposures and so forth.
But, SW has never actually been an engineering discipline. So there's no real way to make things better off the blocks or fix them once they're out. But key problems really have to do with people not things. People are the weak link. And as long as you have to rely on people it will remain the weak link. A better approach would be to take a more holistic approach to allow for vulnerabilities of a given scope and size and build around them as it were. For example if you know that your servers won't get patched very well then fence them off so they can't hurt very much even where they're badly broken. If workstations are infected because people are retards who click on anything, fence them off too so even when they do they can't propagate their own mistakes.
Moreover, you have to understand that not every vulnerability means the same thing. Some things simply won't hurt your company the same way something else will. Heartbleed while a big problem and very pervasive is still only going to point to 64k ram volatile memory blocks. Blow your stuff out before it gets there. Not every unpatched system not every firewall rule will actually hurt your company or conversely its fix help you.
You need to understand that being 98 or 99% healthy is ok too.
The "Security Industry" makes money for the shareholders selling "stuff". Any time they see a problem, they will treat it as an opportunity to sell more stuff, since that is how they make money. If the problem is because the customer has already bought too much stuff, they will still try to sell the customer more stuff since THAT IS WHAT THEY DO.
So if you want to be secure, what do you do? We all know: You get rid of crappy software, simplify your systems, remove unnecessary cruft and hire developers, network systems people and architects who can build you what you need securely. You do NOT hire the cheapest meat puppets who can find the company website and spell "javascript" and you don't outsource your security to the lowest bidder.
This requires real effort on the part of the company paying for all this: They need to recognize that the "Security Industry" and their shiny, happy sales droids are just parasites ripping off the public with the "latest and greatest security stuff that will really protect you this time I promise not like all the other times, I really really mean it THIS time!".
They really need to understand that the RIGHT way to GET Security is to design it in, have the right people building and managing it and proper oversight over all of it. To do that you have to treat it as a profession and a core part of what the company does, not as a "service" or "product" that can be "bought in" or "outsourced" to a low bidder.
Security needs to be treated as a profession in any company with a significant cyber presence, just like the accounting them, the legal team and the core business functions. Pretending it's "just something that we can buy from a vendor" is short sighted and ignorant.
Sometimes the "writing on the wall" is blood spatter...
Thanks to all of this, and the NSA/GCHQ Orwellian Internet world, I no longer do any commerce online.
Online for me now is chatting, posting, blogging, /., emailing, sharing source code.
I no longer do any purchases, or access any online systems that deal with money (banks, credit unions, etc), via the Internet.
Even in the real world, I try to only get my cash via walk-up to a bank teller. No more ATM use. No more credit card/debit card use, if I can at all help it.
Is trying to do a cash-only lifestyle a total time suck, and inconvenient? Yep.
I am certain I can still be a victim, but I am doing what little I can to not be an easier target.
"Always look on the bright, side of life..." -- Monty Python
Uh, Linux geek since 1999.
The company doesn't work for the stockholders. The company has a mission, and the stockholders who don't agree with it are simply not your stockholders in the first place. They don't bother. The founders of a company are free to set the mission as they see fit. The mission doesn't have to be 100% profit- or ROI-oriented. It's perfectly possible to have a public corporation that's after greater things than money. Just because for example Microsoft isn't set up this way doesn't mean it's a law of nature. Far from it.
A successful API design takes a mixture of software design and pedagogy.
Today during an architectural review.... (Architect) Where is the performance data? (Developer) I planned on doing that during a later sprint. (Architect) Can you guarantee that it will get done? (Developer) We can just roll this to production, it's not used anywhere. (Architect) facepalm, facepalm, facepalm....
The title (of both the slashdot post and the original article) is misleading.
The article cites one Eugene Spatford who observes that, "software makers churn out products riddled with vulnerabilities." That's not the security industry's fault.
He goes on to tell us that law enforcement is inadequately equipped and that criminals protect themselves by bribing government officials. That's not the security industry's fault either.
Of the tools the security industry does use regularly he says that, "We’re using all these tools on a regular basis because the underlying software isn’t trustworthy." Again that's not the security industry at fault.
And the solution?
"... an investment in computer programming education and a major move by software manufacturers to embed software security concepts early into the development process."
Sounds reasonable to me. Also sounds like a task for the software development community generally, NOT just those specialising in security.
Never trust a man in a blue trench coat, Never drive a car when you're dead
Human error may always exist, but I think the point is that people aren't learning from their errors. With software, you can find a problem, fix it, and then iterate until all the problems that can be encountered are handled. if you build in robust modules there is a point where you start to see less and less errors being introduced into the code. That isn't currently happening. If we really want to, we can build truly bullet proof code modules but it would take a substantial change in the way things are done.
Suggesting that human error will always exist that therefore there isn't any point in trying to reduce or remove it is lazy and stupid.
HA! I just wasted some of your bandwidth with a frivolous sig!
reminds me of a previous company.
It had a very well designed 3 tier architecture with a good set of security policies. One of which was that the web servers didn't have any connection tot he database servers, not even cabled.
Then the director of a acquired company was told his PHP website was to be put on the production servers, his attitude was one of "well, we'll put the web site on the webservers and just punch a hole in the firewall to the DB".
When he was told that couldn't physically be done... his attitude was "ok, we'll have to install the PHP website on the application servers then and route web requests to it".
I wasn't impressed.
Why can't a software engineer make something that is as reliable as a bridge? Because a bridge costs a flipping fortune and can't really be reworked after implementation, so there's a huge incentive to get the entire team together to get it right.
It's more than that, many software developers (and their employers!) just don't care.
Yes, it is difficult to develop bug-free software. But it isn't that difficult to write a program that validates its inputs, separates privileges, and crashes reasonably gracefully instead of providing complete pwnership of the system.
Example: adobe flash is a 19 megabyte installer. That is a small program. Flash continues to be one of the leading vectors to compromise a system. There has been a continuous stream of flash exploits ever since flash was released to the public.
Making a secure version of flash wouldn't be that difficult, if adobe cared to do so.
In all fairness to "software engineers", this discipline is so new it is a joke to call it engineering. Civil engineering is centuries old with more than a few huge heaps of rubble created when they pushed outside of their bounds of knowledge at the time. Lots of exploding steam engines and crashed airplanes before best practices were codified in those disciplines. Real engineers have to pass a professional exam. You could try the same thing for software engineers but the exam would be meaningless almost before anybody could take it. That tells you the discipline is too new to called engineering however comforting the title may be. Give it another 50-100 years until it settles down. Right now, programming is more of a craft than an engineering discipline.
Sorry, and I know I'll be very unpopular for this, but the blame is on YOU. Yes, YOU. You there who always have to buy the latest and greatest turd that someone puts into a shiny, sleek piece of plastic and calls it the NEW $whatevergadget. As long as you buy buggy, crappy, spyware-attracting, insecure shit just because OHHHH! SHINY! you get what you deserve.
Welcome to capitalism. If I can sell you a piece of turd that stinks, why should I waste money on perfume?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I use to have a retirement account with a certain financial services company. They stored my password in plain text. To recover your password they would physically mail it to you. This kind of stupidity should be illegal. It should be criminal and the company should have to pay fines for being asshats.
Companies don't fix underlying problems because management doesn't see any value in doing so. They also see no risk in having insecure products. Until there are real financial penalties for blatant incompetence regarding security nothing will improve.
The problem is that we see it leak and we still pump more water into the tank instead of finally draining it and buying a new one.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
That's how it should work. But it is always up to management at some level to take responsibility to make sure someone competent is holding whoever is below accountable. This does not happen when there is a disconnect between the business team and the software team. And in most companies, there is a disconnect.
I've got over a decade of working on networked, embedded devices. With the exception of content security, I have never in my recollection been on a project where a significant effort was devoted to the security of the system.
I've worked for a company who made devices which process electronic payments. I asked them about security and whether they ever did an audit. The SW veep's response was "We use SSL."
No one wants to think about it. Security is a hard problem and it blows budgets. Forgetting about security during development rarely(never, really) costs anyone a job.
Marketing and management need to require it before the money generates the will to fix it.
http://www.masturbateforpeace.com/
Up until about 1985 phone sales thieves were more than welcomed to Florida as long as they did not make sales within the state. Local politicians were only concerned with money being brought into town and had no concern about losses by people in other states or nations. Although there was a bit of a crack down it really remains somewhat true today. Cyber crime on an international level may well benefit towns in other nations. After all the thieves buy pizzas at local restaurants and cars at local car lots. Trying to get other nations to spend money stopping cyber theft is not likely to have great success. When we see nations like Russia or China allowing a lot of cyber crime we would either have to put trade sanctions in place or cut their access to the net which would be quite difficult. Organized cyber criminals will simply move to other nations and keep right on doing what they do just as some American phone sales scams are conducted by American sales people working in Burma and other nations. That call that sounds like your neighbor may be quite international these days and it may be your neighbor all those thousands of miles away.
Even though I give you only a 2 on the Open Troll Scale, you made my head hurt enough that I feel the pressing urge to write a reply.
First of all, MS systems are surprisingly stable and secure. It hurts me to actually admit it (and I still say the main source for the security of Win8 stems from even malware writers not being able to figure the turd out), but MS has come a long way, its system offers a fair amount of stability and security and they are very quickly reacting to discoveries. Some of their "solutions" are ... let's say lacking (like their memory address randomization or the TCP packet number randomization, both sucking in ways that make you wonder... but I ramble), but considering their market share and hence how interesting a target they are, I'd wonder how other systems would be doing.
The main attack vector these days is popular third party software. Flash and Acrobat Reader have been widely used, the same applies to popular browsers. All of them because they enable very simple and efficient online attacks that are hard to avoid by the users (online advertising being one of the big issues here). Another attack vector that has been tried and that I'd dare say will become increasingly important in the future is games. Considering how popular certain games are and how most of them routinely require an online connection, either to communicate with servers or for online activation and DRM, they would make a great attack vehicle: People are used to disabling UAC and antivirus systems for games (because they conflict with DRM), they are used to having to open ports on their routers to make them work and if that makes the game work, they will quickly forget about anything "odd".
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Target customers should have filed a class action lawsuit. The evidence is pretty clear that Target flubbed the dub. Let Target look over its shoulder for responsible parties it can sue for damages. Let those look for scapegoats, as well. The buck stops somewhere. Someone didn't plug holes or a software has an exploit or an operating system is porous. In other cases (see Snowden, see Manning) the problem is non-hardware/software related. The justice department should have filed charges for dereliction. The custodians of the data have got to have an incentive to lock the freaking doors.
It little behooves the best of us to comment on the rest of us.
Uh, Gene *IS* an expert. He was one of the first guys to dissect the Morris worm, for example. He's been around from the beginning.
http://en.wikipedia.org/wiki/Gene_Spafford
Maybe you should go FIND a fuck to give.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
engineers have the power to say no to boss about stuff and have licenses on the line.
Target outsourced all / most / some of there IT
and it seems like at least that some of software alerts may of got lost at help desk India
Gene is one of the few people who became a "security expert" not because he called himself one, but everyone else did.
"To those who are overly cautious, everything is impossible. "
The major source of security issues is the bloated, complex software that we use. So as a first step how about a new standard "Secure HTML". It would look a lot like HTML 4.0 but with many things removed. Of course no JavaScript, IFrames or CSS. Very simple formatting. Content on a page would need to come form the same domain (no request forging). Links of page would always show the off page address, in plain ASCII. Etc.
Just enough to provide functional web pages without glitz. The goal being to make the entire browser code no bigger than the original Mosaic code. So that it can be thoroughly reviewed and made really bug free.
Normal users would not touch it. But for anyone with access to a SCADA system, for example, it could be mandatory. That cuts down one major source of infection.
People will run malware for pennies.
The programmers, sysadmins, and netadmins can only do so much. If you completely lock them down, the users can't do their jobs effectively and/or whine and complain and not buy your software or use your service.
People do pay more for bulletproof software and systems, but most people aren't buying airliners.
They're not sockpuppets. They're merely "backup accounts".
You can't spell "oneiromancy" without "roman".
I find that a group of novices is just fine to work with as long as there is somebody with enough experience to guide them (in this case that somebody being myself)
Nobody sticks around longer than a week, huh?
You can't spell "oneiromancy" without "roman".
[...] we refuse to accept old, working stuff.
To me the situation has been exactly the opposite. I had a job where I had to fight to get old crapware rewritten because "it provably works" (although it has e.g. access after "free"). I have never seen an old software that would work with the new requirements in the new environment. Quite contrary, old software slowly but surely deteriorates with #ifdefs, code nobody dares to remove, hacks that just happen to work as they change timing, you name it. Just like good-old OpenSSL.
Same with bridges btw, 20th century bridge would hardly suffice today (price, time to build, etc.).
very few ever see a dietician before a Dr.
Does Dr. Oz's talk show count?
Sell the treatment and get a decade of revenue stream until the patent runs out. Sell the cure and your patients will live long enough that you can sell treatments for other conditions they run into.
The problem is that basically all software is connected to the Internet in some way these days and a lot of the makers of software do not qualify as part of the "security industry" and really have no clue and no interest in making things secure.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Bridges have massive error tolerances built into the design. A single bolt/rivet failing won't bring down a bridge. Bridges are designed to cope with these sorts of failures.
Software as almost zero tolerance for errors. A single bit error can destroy a program.
So how did information get from the database to the web servers or visa versa?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Systems today are too complex for the users, and even the supposed administrators to understand... And all these added layers of extra "security product" just compound the problem. Many organisations are simply unaware of all the risks because they have no idea how most of these things actually work.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Software is often more expensive than the hardware it runs on, and yet you still have a warranty which provides repair/replacement in the event of physical defects but nothing in the case of software defects.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Of course, if some morons decide instead of to fix problems to try to exploit them -- and to create a market for them, the problem sure is to grow even more.
"Yes, this car may be tipping over very easily, but we might need this to assassinate some foreign dignitaries, so we don't hell the manufacturer".
"The more prohibitions there are, The poorer the people will be" -- Lao Tse
it was a 3 tier system.. web servers talked to app servers which talked to the DB server.
Each comms channel was secured so if an attacker exploited the web server (as happens too often) then the attacker had to get past the other layers of security to even reach the DB, let alone export any customer passwords. When you realise many of the modules running on the app servers had limited access to the DB too, you realise that it was as secure as you're likely to get.
Gene?
It's been 20 years or so since I've known him, but does he no longer go by Spaff?
It's simple, when ever you hear a developer pass up C for something stupidity overloaded and abstracted like Java, C++, C# or Python, you lose security. When ever you put an IT "professional" in place that doesn't understand how the operating systems work and thinks that Windows is the suitable for the server, you lose security. The fact is when ever you decide to take the easy road out of no-where, chances are you're introducing security flaws. This is a two step issue, first at the development level and second at the IT level.
This has nothing to do with the security industry, and everything to do with people who prefer to buy the cheapest product rather than a better quality product.
Further, this will continue to happen as long as the software industry maintains it's age-ist view that 'younger is better'. Younger people are not going to have the experience level of older people, which means they will be much more likely to make all sorts of mistakes that older people (who had also made those mistakes when they were younger, but learned from them) won't.
Between the two, there is simply no hope at all that we can have products that are anything more than mediocre quality.
I am an infosec veteran and largely agree with the notion that the bad guys are winning. After reading through the comments section, many seem to be of the opinion that "secure" software means that it cannot be defeated by anyone. Thats never going to be the case. Every security system can be defeated, especially when people are involved, which probably accounts for all of them. There is no such thing as a perfectly secure system.
So that's your recipe for success? Hire cheap replaceable cogs? It's been done do to death and it has it's own set of problems.
Cheap storage VM.
Alrighty. Seems sane. Yes the guy was a dick.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
https://www.youtube.com/watch?...
C++, properly used, is a lot more secure than C. For example, array or string overflows are eliminated by use of std::vector, std::string, and using the .at() subscript notation rather than [].
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Buffer overflows should always be managed by the programmer and never by the compiler. When the developer trusts the compiler over his own ability then he will always introduce security flaws. When the developer trusts himself over the compiler then he will most of the time write better and more secure code. The problem with object oriented languages and any language which attempts to bounds check for you is that it turns developers into lazy moneys and takes all the work away from programming.
...this will continue to happen as long as the software industry maintains it's age-ist view that 'younger is better'. Younger people are not going to have the experience level of older people, which means they will be much more likely to make all sorts of mistakes that older people (who had also made those mistakes when they were younger, but learned from them) won't. Between the two, there is simply no hope at all that we can have products that are anything more than mediocre quality.
THIS.
"Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
Huh? Are you saying everybody should hand-code assembly without any sort of framework?
Buffer overflows should be managed by the language. Any security feature that the language can handle should be handled by the language. This frees the programmer to think about what's going on on a larger scale. Humans are really not good at making sure every instance of a common pattern is handled correctly, and compilers are.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
No, I would never make such an insane statement but it's extremely important that as a programmer you trust your own abilities over that of a compiler.
A great test to give any interviewer for a job is to give them a piece of C code which has had things like bounds checking removed, structure attributes removed, pointer checks removed and so on and see if they put them back in before they finish the task at hand. I can honestly say from experience and having to go through these type of interview submissions that 90%+ of the time, the programmers who don't put checks back into the code, write piss poor, frame work managed style code. What kind of confidence are you going to instill in me when you don't even take the time if wrap an array check with an if statement? Usually when I go back and ask the interviewer why it's left out I get the classic, "Well why doesn't the compiler make sure you don't write off the end of the buffer? That seems like a design issue and I shouldn't have to manually do it!"
It would be really hard to look a client in the face and tell them that there brand new million dollar embedded system failed because someone, an object oriented programmer, decided that the array or list would check itself before corrupting memory.