Ask Slashdot: How Are So Many Security Vulnerabilities Possible?

dryriver writes: It seems like not a day goes by on Slashdot and elsewhere on the intertubes that you don't read a story headline reading "Company_Name Product_Name Has Critical Vulnerability That Allows Hackers To Description_Of_Bad_Things_Vulnerability_Allows_To_Happen." A lot of it is big brand products as well. How, in the 21st century, is this possible, and with such frequency? Is software running on electronic hardware invariably open to hacking if someone just tries long and hard enough? Or are the product manufacturers simply careless or cutting corners in their product designs? If you create something that communicates with other things electronically, is there no way at all to ensure that the device is practically unhackable?

Comments

10/90

[rudy_wayne]

Is software running on electronic hardware invariably open to hacking if someone just tries long and hard enough?

This is 10% of the problem

Or are the product manufacturers simply careless or cutting corners in their product designs?

This is 90% of the problem.

Re:10/90

[Narcocide]

Yes, the big issue here is that it's common knowledge consumers by and large refuse to be bothered to get educated and the bulk of the major software development companies out there aren't don't have leadership ethical enough to be able to resist taking maximum possible advantage of their naivety. Unfortunately this knowledge gap is also being turned against our own government even as our own government participates in using the very same knowledge gap on the general population. It's a huge ugly mess, really, and it says a lot about the spiritual deficiencies of humans as a whole, and I still completely in all seriousness blame Microsoft for starting it.

Re:10/90

[Anonymous Coward]

Or are the product manufacturers simply careless or cutting corners in their product designs?

This is 90% of the problem.

This, so much this. Companies still view security as something that costs too much money to implement properly. It's cheaper to deal with the financial loss of a hack, than it is to have decent security policies implemented with properly trained personnel who's responsible for patching security vulnerabilities and testing the network constantly. Security's a constantly changing state of being, but this last statement shouldn't really be news for the crowd who's drawn to reading ./

Re:10/90

[Anonymous Coward]

And the other 100% of the problem is that no one takes updates regularly.

Re:10/90

[Apocryphos]

I have been sitting on an android update for my phone for probably the last 3 weeks. I just never notice it when it's convenient to update. I once went 9 months with a pending update because I didn't have enough free space to download it. There's no way to prevent software from having bugs, but a better update model could reduce their longevity in the wild.

Re:10/90

[140Mandak262Jamuna]

You should not have to update. That should be the goal.

Re: 10/90

[Anonymous Coward]

"How in the 21st century, is this possible..."

-Some Genius on /. who thinks all the work is done already.

Hey, pointing out that's it's the 21st century actually answers your question.
The technology is super young. We're not even 20% into the 21st century and computers were invented in the 2nd half of the 20th century. And they didn't even have operating systems for a long time.

Re:10/90

[ZorinLynx]

Android doesn't have an "update overnight" option like iOS does?

Most of my non-techie friends with iPhones just hit "update overnight" and the update is done by morning; no interruption to their routine.

Re: 10/90

[Zero__Kelvin]

I like to update the bugs in my software daily when I can.

Re:10/90

[Anonymous Coward]

So even if you fixed the 90% that is stupid programming, you would then have 100% non-preventable vulnerabilities?

Re: 10/90

[Zero__Kelvin]

You left out the other 99% of the problem... software that ISN'T running on computer hardware; That's right... wetware. Humans are involved, and any time you have humans involved trouble and hilarity are sure to ensue.

Re:10/90

[Anonymous Coward]

If you have zero free time in three weeks, security isn't your main problem. Sure it will bite you in the arse, but you'll have worse things to worry about.

Re:10/90

[Anonymous Coward]

One of the most careless things "product manufacturers" do is allow their staff to program in languages that don't have built-in validity checking. When you create a scalar variable you should be able to tell the compiler the list (or ranges) of valid values, and it should throw an exception if that's violated; when you create an array you should be able to tell the compiler the valid range of subscripts, and it should throw an exception if that's violated.

This will avoid the vast majority of bugs, both during dev and in deployment.

Now, cue the hyper-inflated egos who think they can do this more efficiently than a well-designed compiler. Sure, there are a few very detail-oriented programmers who may be able to do that; however, (1) you probably aren't one of them; and (2) even if you are, it's highly unlikely that any of the people who will maintain your code after you move on to a different project/company are among them.

To simplify, C is an abomination. It, and its relatives and descendants should be purged, and everyone who loves them should be sent for psych counseling./snark

Re:10/90

[Anonymous Coward]

Liability. The manufacturers and sellers of this fast and loose madness have a seemingly impossible level of impunity. Once a consumer purchases item "X" with Hardware version "Y" and Software version "Z" they are stuck with the end-product.

There are multiple flavors here:

1) The vendor provides support.. but limits the number of weeks/months/years... This is you Apple and multiple top-tier Android phone vendors!
2) The vendor provides support.. but decides to alter the deal (Cue the Darth Vader music..) I've sadly dealt with this with my QNAP NAS (bye-bye.. Twonky... I purchased my QNAP based on this feature)
3) The vendor provides a product that is locked in at the time of purchase... with no ability to upgrade (this includes tens of thousands of fixed-island android iterations of phones/tablets/Internet-of-Trash)
4) Some iteration or permutation of 1/2/3

Peace out.

Re:10/90

[AlanObject]

It's cheaper to deal with the financial loss of a hack, than it is to have decent security policies implemented ... ./

Actually in many (if not most) cases the people making the decisions simply don't think it will really happen to them.

Re:10/90

[Junta]

Eh, I'd say it's not guaranteed that anything is invariably open to hacking.

I'd say 15% vendors are crap, 85% users/admins picking the password 'password' to secure things.

In the world of IoT of course, it goes to 100% crappy vendors.

Re:10/90

[l0n3s0m3phr34k]

My Samsung does. However, if the phone just doesn't have "enough room" that doesn't help much.

Re:10/90

[UnknownSoldier]

Murphy's Computer Laws

Meskimen's Law
There is never time to do it right, but there is always time to do it over.

Note: Murphy was an optimist.

Re:10/90

[hcs_$reboot]

This is 90% of the problem.

And 90% of those 90% are due to cheaper inexperienced or incompetent people in charge of implementing security.

Re: 10/90

[Anonymous Coward]

Rather than use technology to secure, we should be using technology to give potential attackers whatever they want in a virtual way. Use tech to eliminate the motivations to do harm. Do away with passwords, let everyone post what they wish as whoever they wish. Use filters to customize your view of the world. Be more imaginative than trying to control ppl by locking them out of some virtual resource. Give access to all and use tech to sandbox harmful impulses.

Re:10/90

[Anonymous Coward]

I bet they insure against hacks. The insurance is cheaper than security. The insurance company pays out against assets that are financial promises to pay at some future date, i.e. promises for the future are circulating as money today. When those promises come due, many financial options can eliminate any bad effects of a default. Promises (loans) can be rolled over. Balance sheets can be further expanded to accomodate the promises, giving them new life even though they weren't kept. Insurance can pay out on the promises, and the insurers themselves are borrowing against still future promises to pay, which when they come due can be rolled over or hedged and thus the cycle continues ...

Re:10/90

[Anonymous Coward]

updates should tell you what the hell is going on and give you a choice about whether you want it.

Re: 10/90

[TimMD909]

Bounds checking and validation on every single operation on all variables? Gee... that couldn't have negative performance implications.

Re:10/90

[Anonymous Coward]

Well more like the hacker only has to be right once; and the defender has to be correct every single time.

Re: 10/90

[BlueStrat]

...any time you have humans involved trouble and hilarity are sure to ensue.

You forgot needless, senseless, totally-avoidable, self-inflected tragedy and suffering. Lots and lots of tragedy and suffering. The ratio of tragedy and suffering to trouble and hilarity roughly resembles that of the ratio of spam to anything else on the diner menu in the Monty Python "Spam" sketch.

Well, there's spam egg sausage and spam, that's not got much spam in it.

Strat

Re:10/90

[jellomizer]

Actually it is far more complex.
1. Legacy systems and backwards compatibility: A lot of software we still use have roots in the pre-internet days. Where having a UI password with a weekly encrypted password was considered strong security. Most hacking back then would had been finding a service that didn’t need a password and exploited it by just using it. By the Mid 1990’s more systems were getting on the internet allowing data to be sent without the UI so buffer overflows were a big thing and URL hacking. We have millions/billions of lines of code already made in production to dump it all and do a full rewrite of 20 years of logic is too expensive and risky because there will be 20 years of learned mistakes that will happen.

2. Programming language are good at writing particular programs. Programs are made to do something unique. So we get are basic programming language designed for a CRUD programming. The requirement require it to transfer data to different systems, take real time monitoring of other things, and log and audit to the extreme. So we run across challenges nearly on a daily level where we need to stretch what the language is good for. This creates openings to problems, switching to a lower level call means you will need to think of all the ways it can be broken, while at the same time you are just trying to accomplish its main objective.

3. If we had unlimited time, nothing will go out the door. We love to fester at the bosses to push the product out the door quickly. But to be honest a product is never good enough. There is always more we can do to make it better.

Re:10/90

[Anonymous Coward]

This is 90% of the problem.

This might be true. When concerns about information security are met with tinfoil hat jokes and ridiculing, few programmers keep trying. After few fruitless attempts mindset changes to: "you motherfuckers will reap what you sow and then I will remind you about your stupid tinfoil hat jokes".

Re:10/90

[The Cynical Critic]

What you're talking about are the symptoms, not the root cause. The actual root cause is that consumers don't really care about security or how well made a product actually is. What a consumer cares most about is what the product does, it's outward appearance, the user experience and cost. Security is something a fraction of them get outraged over when it goes wrong, but it's not really relevant to them when they make the actual purchase decision and if they eventually begin to regret that they didn't consider it, this is generally not going to happen until after the returns window has closed.

In the end it all really boils down to consumer priorities and those priorities not really providing any incentives for companies to make security a priority. When the return on investment from spending time and money on additional features or an improved user experience is much greater than spending that time and money on properly securing a product, security efforts just won't get the budget they need.

Re:10/90

[Bongo]

Kinda, but also, people have embraced the technology so fast that we can now do things we did not imagine -- and therein lies the rub, because whilst we didn't imagine what positives would be possible, we also didn't imagine what negatives would be possible. It is something of a blind process.

So, now we start to get experience of the negatives, and like anything else, we have to start trying to remedy them, just like with cars, where everyone who could, got one, and then we were horrified at how badly they mangled bodies in accidents. So then they started adding safety features. And people still die in accidents, but nobody is going to stop driving. And that is the cost.

I'm not sure which spiritual aspects you mean, maybe more about integrity, but imagination and creativity and play are also spiritual qualities, and there is a certain amount of egg-breaking involved.

Re:10/90

[Anonymous Coward]

I agree most of the time the real issue is that company dont want to test for security as for many things I think about that 80/20 proportion. It takes 20% of effort to remove 80% of the bug, but it takes 80% of energy to remove the last 20% bug and those are often the security vulnerability. Computer security is very complex sometimes.

Re:10/90

[gweihir]

Indeed. Developer incompetence is 90% of the problem. Languages, coding styles, etc. do not really matter. Incompetent coders demonstrate time and again that they can make it insecure, no matter what.

Re:10/90

[djinn6]

Why update when your system works properly? I don't think I've ever had a major update on any OS that kept everything in working order (whether it was Windows, OSX, Linux or Android). They always manage to break something in the update and I have to spend hours tracking down a fix, assuming one even exists.

Re:10/90

[Ol Olsoc]

My Samsung does. However, if the phone just doesn't have "enough room" that doesn't help much.

I wonder what could be done about that?

You have to help the company a little - clear the darn thing out.

Re:10/90

[Anonymous Coward]

I'm pretty confident out of those 85% there are at least 60% vendors that are crap and don't give users a usable or at least better way to secure things than having a password.
Developers need to learn that 50% of users choosing something like 'password' as their password is totally their fault, not the user's fault.
Blaming users certainly is a significant source of security issues (sometimes also more literally, when bug reports are ignored because they "used it wrong" even though it's a glaring security issue).

Re:10/90

[MikeB0Lton]

Agile methodologies emphasize fast results and embrace failure. Everything is iteration and continuous improvement. To secure a product, security has to be given priority over enhancement in the sprint. Fat chance of that happening.

Re: 10/90

[Anonymous Coward]

And if a programmer makes a mistake in defining the "allowed" range?

Re:10/90

[Anonymous Coward]

Ah, so that is why compared to all other things, almost no security issues are ever discovered in Java programs or Android apps!
Or why Java deserialization is not a complete security crapfest that is 100x easier to exploit and hard to mitigate than even the simplest stack buffer overflow.
Guess what, if the exploit mechanism is a core part of your language, it does not make the language safer but the opposite.
You know what would help actual security a lot more than a new shiny, unproven language that solves exactly one of the 100s of ways to cause a security issue? Especially since you talk about "throw exception", which probably in a few years someone will come up with ways to exploit in 20% of all programs in a way that is vastly easier and more reliable for the attacker. You know that the point is not to make it easier for the HACKERS by giving them more reliable attack vectors?
You know what might actually help? The ability to easily prove correctness right while programming at least for the simpler properties for example. Funnily for the few tools that actually exist, C is actually best supported.
Nothing can save you if a developer that doesn't have a clue and doesn't care develops the code.
If they care, safer languages will protect them from some bugs. Lack of tooling will mean they lose protection and mitigation for other bugs.

Re:10/90

[ctilsie242]

Even without insurance, the cost of a breach is most often lower than taking proper measures and coding to not have it happen. Every company that has had a major breach has recovered in 6-12 months at most. Even Equifax's stock just lost a year's worth of gains and is on its way back up.

The only thing that can stop this is government regulation, or contractual agreements like PCI-DSS, which actually put pain where it matters... at the pocketbook.

Re:10/90

[MyrddinBach]

My wife has an iPhone and has not been able to update it for several months because she doesn't have enough space on it to install the update.

She can't even update most of her apps (of which she doesn't have that many) due to the limited amount of space she has on her phone.

Re:10/90

[skids]

Companies still view security as something that costs too much money to implement properly.

Money and time. Really it boils down to: your business fails if your software has less features, now, than the competitor, even if it is 100 times more secure.

Re: 10/90

[Anonymous Coward]

Not sure how you correlate the cost of taking proper measures with how long it takes stock prices to recover.

Re:10/90

[l0n3s0m3phr34k]

Indeed. Probably would help quite a bit with battery life if it's a bunch of apps; microSD cards are pretty cheap these days too...

Re:10/90

[david_thornley]

The fundamental problem is a lack of liability. If a company gets lots of its data leaked, there's no real consequences. Companies do what makes them money. If data breaches cost them a lot of money, they'd work to avoid them. They'd buy insurance, and insurance companies are very good at assessing risk, so the company's insurance would be cheaper if they did a good job on security. At that point, it's a business expense to be balanced with others. If companies demanded secure hardware and software, they'd get it.

Re: 10/90

[Anonymous Coward]

For every programmer who writes and deploys code where absolute fastest performance is a requirement there are 8,000 who pretend they do.

We aren't using Rust enough.

[Anonymous Coward]

The problem is that we aren't using safe-by-design programming languages like Rust enough. If we used Rust more, then many types of bugs and security flaws wouldn't even be possible. As more and more software developers follow Mozilla's lead and start to use Rust to build their software systems, we will see many common types of security flaws vanish.

Re:We aren't using Rust enough.

[Anonymous Coward]

Yup. But youâ(TM)d also be running your applications at speeds comparable to modern Java implementations.

Re:We aren't using Rust enough.

[Narcocide]

Just in case the uninitiated might confuse this for a serious statement; to be clear he's completely trolling.

Re: We aren't using Rust enough.

[Anonymous Coward]

Actually, Rust runs blazingly fast. It uses zero-cost abstractions and a minimal runtime so it has very little overhead. It also uses move semantics to avoid needing inefficient garbage collection strategies. In addition to that Rust also has threads without data races and guaranteed memory safety which makes it easier to write highly parallel code that takes advantage of all of the cores in modern processors. Rust code can easily run faster than Java code and it's common for it to run faster than C or C++ code.

Re: We aren't using Rust enough.

[Anonymous Coward]

How is it 'trolling'? Rust has guaranteed memory safety, which does in fact eliminate the possibility of whole families of security flaws. It also has threads without data races, which eliminates yet more families of security flaws. Rust has been designed to prevent segfaults. It has been designed to avoid the problems with C and C++ that allow for security flaws to be introduced into code.

There's no reason for you to hate Rust. If you feel it's threatening your job as a C programmer, well, it is. You should start learning Rust now because it's a language you'll be using in the near future.

Re: We aren't using Rust enough.

[Anonymous Coward]

Actually the problem is that people like you expect everyone else to do it for you. Instead of admitting you don't know shit, and don't care to learn, you blame the language, the compiler, the API, the library, etc.

It's the Millinial generation's entitlement attitude manifested in code.

Re:We aren't using Rust enough.

[Anonymous Coward]

There's nothing factually wrong with the troll. It's written in a snarky way, but it is essentially correct.

The problem is mostly shit tools. Better tools will help solve the problem.

Re: We aren't using Rust enough.

[Zero__Kelvin]

You should avoid Rust and use my new language WD40, which gets rid of the biggest security problem in the industry: programmers who think there is a computer language that is a panacea.

Re: We aren't using Rust enough.

[Anonymous Coward]

Yeah right, I should be taking seriously every other cocksucking language, especially with a stupid hipster name and a sect of suicidal followers.

Re: We aren't using Rust enough.

[Anonymous Coward]

Rust will run circles around Java, C, and C++ because Rust is web scale.

Re: We aren't using Rust enough.

[Anonymous Coward]

How about making rust syntax look exactly like what's familiar and trusted - like C++?
You want me onboard, make it into C++. Should be simple enough with "geniuses" behind it.

Re: We aren't using Rust enough.

[viperidaenz]

But how does it compare to Mongodb?

Re: We aren't using Rust enough.

[Anonymous Coward]

How about making rust syntax look exactly like what's familiar and trusted - like C++?
You want me onboard, make it into C++. Should be simple enough with "geniuses" behind it.

Who cares about syntax, it is almost literally just window dressing. There are languages with multiple syntaxes. With a preprocessor you can use any syntax you desire. Shit I've seen at least a dozen different "syntaxes" for just plain old C, done with nifty macros. There is a parse tree of the program in your head, get it into the computer. Get over your preoccupation with syntax and look deeper at the actual features of the language.

Re: We aren't using Rust enough.

[Junta]

It does mitigate certain families of security flaws. However most C programmers have had it beat into their head to generally do the right thing, so these are more rare than they used to be, though still real enough to value the language removing the and implementations like rust deserve credit for taking measures that help here..

However it simply cannot magically fix most modern vulnerabilities that get announced, as they are generally oversights in logic flows. So it's a bit worrisome to see people seeming to put a bit *too* much faith in language to provide 'automagic' security, when the design is more often the vulnerability rather than bungling pointers/mallocs/bounds.

Re: We aren't using Rust enough.

[Anonymous Coward]

Rust imposes a higher learning curve, but what GP said is true... it's GC but with no runtime overhead, because GC happens at compile time. So your runtime code is malloc()... then free(). That free() is automatically inserted by the compiler. That's the same speed as C but without having to figure out where to manually place that free() call.

Google "rust ownership borrowing" for more details.

Re: We aren't using Rust enough.

[Anonymous Coward]

A carpenter shouldn't blame his tools: My shop doesn't have power for power tools, so I've learned how to do a lot of things with hand tools. With a lot of practice, I can make a square cut with a hand saw. That said, a chop saw can also make square cuts a hell of a lot faster than I can, and requires less practice. If I was paying some one to cut wood, there is no way I would pay them to use a hand saw outside of special cases, doubly so if it is an expert woodworker who's time costs even more.

Experience and time cost money. Do you want to spend your money on an expert programmer making sure there are no out of bounds memory access, or do you want to spend your money on the programmer solving stuff that isn't easily solved by a better tool? Outside of special cases (e.g. really small embedded setups), use programming time to solve new problems, not to solve and double check ancient problems that can be automated away.

Re: We aren't using Rust enough.

[TechyImmigrant]

>It does mitigate certain families of security flaws.

Crypto types like Rust because it deals with a particular class of problem that is impossible to mitigate in C. Namely knowing what the compiler will do, for sure. Will it erase that buffer or will it optimize it away the erasure? In C there are a wealth of examples where code that compiles to secure object code on one compiler manage to get broken by another compiler. Or when the optimization level is changed. There is no "Best Practice" to make this problem go away using C. Rust specifically address this problem and while the other safety features are nice for mitigating security vulnerabilities, it is that specific problem that makes Rust appealing to the people who have looked under the compiler hood from a security standpoint.

Re: We aren't using Rust enough.

[phantomfive]

If I had to guess, the two most common security flaws are "sql injection" and "XSS." C buffer overflow is distant in the ranking, and exploiting it is even harder (because of kernel protections in every kernel).

Re: We aren't using Rust enough.

[Dasher42]

There are no panaceas in programming languages, but working with a framework that is carefully well-designed sure does cut down on human error down the road, even in the hands of a skilled programmer.

Ada is de facto for onboard systems in airplanes for a reason. Language constructs for design-by-contract matter when it's important, and we're learning from the masses of botnets and hackery that there's a lot that matters, not just hospital systems and jet planes.

Rust is in fact building important features into the core that C++ is just trying to bolt on. We need less error-prone, more validated and tested code, and the frameworks to support that. We're designing systems that society relies on, and it's irresponsible to society to assume that every programmer is a rock star 100% of the time.

Re: We aren't using Rust enough.

[Anonymous Coward]

There is the impedance problem. Translating my natural language idea into some arbitrary syntax can be unnecessarily taxing.

Re:We aren't using Rust enough.

[IAN]

Just in case the uninitiated might confuse this for a serious statement; to be clear he's completely trolling.

It is a species of trolling, designed to attract flaming responses and try to paint Rust proponents as arrogant, insufferable know-it-alls whose opinion can be safely dismissed. There's nothing factually wrong in that statement, it's all in the approach.

Non-trolling assessment would be that Rust's safety guarantees help, and help enormously, with the development of robust code, but are not a panacea. E.g., see the results of fuzzing some Rust programs and libraries: those are all bugs detected at runtime, not by the compiler. Note also that all except two, one segfault and one stack overflow, result in a controlled crash with a backtrace, which makes identifying the bug much easier.

It is also clear to everyone who's not a blind zealot that it's impracticable to re-implement every piece of code in Rust. Which doesn't mean that its use in places where it's felt that its safety could make a difference shouldn't be explored.

Re: We aren't using Rust enough.

[Anonymous Coward]

impossible to mitigate in C. Namely knowing what the compiler will do, for sure.

If you don't know what a C compiler will do if you do something, you should not be doing that thing. If you don't know what a C compiler will do period, you should not be doing programming. In any language.
Neither Rust nor any other trendy rattlebox is a brain prosthesis. Deal with that.

Re:We aren't using Rust enough.

[Anonymous Coward]

Rust is a good language, but you can get the same protections using C++ templates. You loose a bit of the C++ speed advantage though, but that almost never matters.

Re:We aren't using Rust enough.

[Anonymous Coward]

If Rust is safe by design, Firefox and rust are like matter and anti-matter.

Combining the two would result in a huge explosion.

Re: We aren't using Rust enough.

[Junta]

XSS largely caused by web developers overengineering their site and simultaneously lost at how to precisely and accurate describe the policies. Mostly the former, not every situation needs to splatter a web page across half a dozen servers.

Re: We aren't using Rust enough.

[AmiMoJo]

Do you mean C++?

Because in C there are operations with undefined results, but if you avoid using them then the operation of the code is well defined and guaranteed. I know some people dislike it being possible to compile code with undefined results, but with C all those conditions can be caught by static analysis.

C++ on the other hand is not so simple at all.

Re:We aren't using Rust enough.

[gweihir]

Complete and utter bullshit. Language has little to no influence on code security. You can be insecure on many different levels and incompetent coders universally manage to make it insecure.

Incidentally, the claim the Rust is safe-by-design is a shameless lie. It is not. It just makes some specific security issues more difficult (but not impossible) to implement. It does not do anything at all for most security problems.

Re:We aren't using Rust enough.

[gweihir]

With the Rust people you can never tell. They seem to be trolling themselves constantly about the miracles that their "one true language" can do.

Re: We aren't using Rust enough.

[gweihir]

The incompetent among the coders (the majority, unfortunately) is always on the lookout for the next, greatest language or tool that will remove their incompetence. It never pans out. This collective stupidity has been going on for a few decades and it is always nonsense.

Re: We aren't using Rust enough.

[gweihir]

Actually this "problem" is easily rectified in C by understanding of the "volatile" keyword. Apparently that is beyond the complexity the people that have this issue can manage.

Re: We aren't using Rust enough.

[gweihir]

Indeed. Buffer overflows in security-critical code are mostly a sign of developer incompetence and they are getting far harder to exploit than other flaws like XSS.

Re: We aren't using Rust enough.

[gweihir]

Indeed. The "somebody else is at fault" people are a plague. They never learn anything from experience, because it is always somebody else that is responsible. Of course, that is usually not true, and hence they stay incompetent.

Their vision of Rust is nothing but a "coding safe space" where the compiler will make even the dumbest fuckup write secure code. Of course, that is not how it actually works.

Re: We aren't using Rust enough.

[coofercat]

Use any language you like, just build the software according to TEFLON standards. Gartner reports that companies that work to TEFLON standards have 40% higher revenues per capita fortnight than those that don't.

Re:We aren't using Rust enough.

[Anonymous Coward]

Fuzzing vastly over-estimates the effectiveness of Rust, because the issues it avoids are those that are easiest to find and fix with it (and lots of other tools).
Fuzzing (in its generic implementations) will not detect if e.g. your program forgets to actually check the password before letting someone log in.
One of the reasons why fuzzing is so useful for C programs is that it is a good way of finding the crappy, thoughtlessly written code.

Re: We aren't using Rust enough.

[Anonymous Coward]

TFW Ada has been in use for 30 years and people are saying there are security vulns everywhere because not enough people use Rust. I think the fact that people believe this shit, and I say this as a bona fide embedded software security expert, is a pretty big part of the problem: too much dumb ass superstition and not enough rigorous engineering.

Re: We aren't using Rust enough.

[Zero__Kelvin]

That is exactly my point. C++ has constructors, destructors, safe pointers like unique_ptr. The problem isn't that a language *lets* you shoot yourself in the foot. The problem is that most of the people shooting shouldn't be allowed anywhere near the gun.

Re: We aren't using Rust enough.

[Anonymous Coward]

If you don't know what a C compiler will do if you do something, you should not be doing that thing.

Right, because you personally check, by hand, every single line of generated assembly, and you of course then also inspect in detail the final machine code. I admire your efforts.

If you don't know what a C compiler will do period, you should not be doing programming.

I see. Every programmer needs to also be a C compiler designer.

In any language.

Interesting. So every programmer needs to also be a C compiler designer, regardless of which programming language they actually use on a daily basis.

Neither Rust nor any other trendy rattlebox is a brain prosthesis.

Sure. Fairly certain nobody has suggested that, but fine, sometimes stating the blindingly obvious can serve a purpose.

Deal with that.

No, because you are a deluded and arrogant little shit, who apparently has no connection to reality whatsoever.

How about you just fuck the hell off and never write another comment here again. Ever.

Slashdot would be better off without you.

Hell, the world would be better off without you.

Deal with that.

Re: We aren't using Rust enough.

[Anonymous Coward]

You should avoid Rust and use my new language WD40, which gets rid of the biggest security problem in the industry: programmers who think there is a computer language that is a panacea.

Preferably auto-applied to the eyeballs once hubris detectors hit 6. If they ever hit 11, cyanide is deployed.

Re:We aren't using Rust enough.

[Anonymous Coward]

Ohhh it's the programming language, not the programmer.

It's the gun, not the operator.

It's the car not the driver.

Re: We aren't using Rust enough.

[wild_berry]

Short for "We Don't hire over 40's."

Get off my lawn, kid.

Re: We aren't using Rust enough.

[david_thornley]

If you can determine where the free() goes, you can solve the Halting Problem.

Re: We aren't using Rust enough.

[Anonymous Coward]

What does that even mean? Rust CAN outperform Java in any scenario since you have dramatically more low level control. Comparable performance, sure...

Re: We aren't using Rust enough.

[TechyImmigrant]

>If you don't know what a C compiler will do if you do something, you should not be doing that thing.

Of course you should. Perhaps think before commenting.

Consider the importance of erasing state in security software.
But if you write zeroes to some key data and let it fall out of scope, a C compiler may or may not optimize away the erasure. There is nothing in the spec to tell you what the compiler will do, but that does not mean you shouldn't erase keys in memory after use.

How things are put together

[Anonymous Coward]

It would seem that programmers are more concerned with WHAT they have to do, and not overconcerned with HOW they do this..... They just the the job done.

Re:How things are put together

[presidenteloco]

I agree that better programming languages with safety features would make a huge difference, if someone can make one that is easy to understand by average or below-average programmers, who write a lot of the software out there. Rust is quite safe, but has a lot of really weird-ass new concepts that many programmers can't be bothered to try to grok. Go is half-decent, but also a moderately weird and finicky programming language.

Safer web-app templating and db access libraries would also help a lot.

Company management wise enough to allow time for up-fron security reviews, tests, and fixes would also help alot. In contrast, most software projects are inherently behind on unrealistic-from-the-get-go schedules.

Re:How things are put together

[TechyImmigrant]

>They just the the job done.

Without necessarily needing to use all the words that would be normally be needed in a sentence.

Security costs money?

[Anonymous Coward]

Good security usually means re-architecting whatever legacy garbage fire has been burning in off in the corner for the last 12 years and that costs money. The insecure software is still generating revenue in it's current state and there are no consequences for poor software security. #Equafax

Re:Security costs money?

[tgeek]

You have three choices when developing your product. Cheap, fast and/or secure. You get to pick two of those.

Re:Security costs money?

[coofercat]

In my experience, GDPR and other legislation with less memorable names here in the EU has pretty much got tech companies shitting themselves. The penalties are so huge it could mean the end of your company if you royally fsck up, and even if you're sort of playing along with the rules, the audits and other 'hazards' to you are still pretty scary.

Take Equifax or Uber - if those hacks take place after May next year, then those companies are in a world of pain. Equifax lost some EU people's data, Uber probably did, but that's not been confirmed yet. Both companies tried not to disclose the hack and/or cover it up. Do that after May, and it's a short ride to the courts to put and end to you and your company.

Roll on May... I'm looking to see who falls first.

Re:Security costs money?

[Anonymous Coward]

I'd be happy with one out of three most of the time...

Agile development

[Anonymous Coward]

Who cares, we have arbitrary deadlines to meet. Ship it broken! We can fix it later.

Re:Agile development

[sinij]

Sprints will continue until developer morale improves!

cucks

[Anonymous Coward]

and government spooks

Also bugs

[Kohath]

How are bugs still possible? That's how security holes are still possible too.

Re:Also bugs

[hcs_$reboot]

Sure. But maybe, also, not enough workforce and money is put on the table when it comes to security ( == they don't care enough )

Re:Also bugs

[Anonymous Coward]

There is no law or rule that says companies must sell bug-free software.

A week or two goes by?

[Known Nutter]

A day goes by when Slashdot originally misses the story they end up posting a week later.

Git-r-done

[Snotnose]

Security issues? Um, have you met the requirements? Yeah? Does it work? Yeah? The security issues aren't in the spec, release it.

The good news is much like Charlie Rose gets embarrassed off the national stage, hopefully companies that don't take security seriously will be forced into bankruptcy.

Re:Git-r-done

[complete loony]

Engineering software typically involves confirming that everything that is supposed to happen, happens. Making software secure involves testing that everything that shouldn't happen, doesn't.

Testing for *every* possible failure case is hard.

Re: Git-r-done

[Anonymous Coward]

Why should Charlie Rose be embarrassed over something simple as a natural desire to fuck chicks.
All men should want to fuck chicks, except for stupid perverts who openly admit to taking it into a butthole, like fagget Tim Cock does.

Re:Git-r-done

[TechyImmigrant]

>Testing for *every* possible failure case is hard.

But a little spot of formal methods can go a long way.

Re:Git-r-done

[AmiMoJo]

Usually the person writing the spec doesn't even know how to specify security. They will write things like "must be secure against hacking", and tick that box because it prompts for a password now and then.

The best advice I have for people with this problem is to specify that a security consultant must evaluate the software.

Re:Git-r-done

[Anonymous Coward]

And yet you listed none of these formal methods...

Re:Git-r-done

[Rob Riggs]

Engineering software is about following industry standard best practices, including those provided by orgs such a CERT. Virtually all software engineering BS programs have security related coursework as an elective, not a requirement for graduation. Until that changes, it's going to be a ugly scene.

Re:Git-r-done

[Anonymous Coward]

"Testing for *every* possible failure case is hard."

No, it's impossible.

Re: Git-r-done

[Anonymous Coward]

Because it was at odds with the other human's natural desire to not get fucked, you fucking fucker.

Re:Git-r-done

[TechyImmigrant]

And yet you listed none of these formal methods...

FEV (Formal Equivalence Testing)
FPV (Formal Property Testing)
Taint Analysis (showing secrets don't have a path out of a circuit, except through the intended paths)

There are lots of such tools. Since I work mostly in hardware, I use tools like jasper for FPV and tools from Synopsys and Cadence for FEV. There are taint analysis tools available but we use an internally developed one.

If you work in software, there are also plenty of tools, like frama-C for FPV on C code.

Re:Git-r-done

[Anonymous Coward]

It is mathematically impossible to prove any nontrivial application as being bug free.

THe most we can do is prove that it does not error or malfunction against known and easily reproduced scenarios. Most of the flaws you are seeing today are zero day exploits (which by definition a company does not know about or cannot predict). Also the issue of zero day exploits in third party tools and controls like what seems to have happened to Equifax or Experian (i forget which company it was).

Then you have the pressure to release fast, go full devOps push the code out with flags that enable you to do something to roll back or roll forward quickly. While the automated unit testing practices are improving in much of the industry, many companies are pursing automation at all cost and throwing out the kind of exploratory testing, and security pen testing, to say nothing about performance testing and benchmarking, as a standard practice in order to cut their personnel costs or just simply to speed release.

If you combine that with I've found is a lack of awareness, training, and tooling being provided to mitigate a lot of low hanging fruit in security testing, it no wonder its happening so often. I've written my representative and told them how much of a 'crisis this is in the country right now', but even the Federal Government seems to not take it that seriously at least not publicly.

Re:Git-r-done

[strikethree]

Testing for *every* possible failure case is hard.

You are doing it wrong.

I wrote a bot for IRC (running on EFNET now for almost 20 years). What I did was drop everything that I was not looking for and if it was what I was looking for and did not fit into what I had created for it to exist in, I dropped it too. No error messages, no alternate program flow, just dropped. Either the data conforms to the protocols at all layers, or it is just dropped. Why attempt to make sense out of it or try to handle the various ways it could be messed up? Just. Drop. It. The bit bucket is a nice friendly place that never fills up. :)

In essence, I did not try to control reality. I controlled myself... and that is a hell of a lot of easier to test.

Yes.

[xxxJonBoyxxx]

>> are the product manufacturers simply careless or cutting corners in their product designs?

Yes.

I've been a software security guru for more than ten years, and none of the companies I worked for, whether Fortune 100 or commercial companies shipping commercial software, fixed all the vulnerabilities we found before shipping. (Some set the bar at "high" and some as "critical", but no one halted the presses for "medium".) For all I know, most of the vulnerabilities we found perished on a disbanded team's backlog years ago to the delight of hackers everywhere.

But the bigger problem would be the code that shipped that we never saw, whether it was an intern's "hackathon" project shat onto the web, something that crawled out of a pool of H1Bs, or a third-party app grafted in to fake reporting enough to get past the demo with the big client. I have more horror stories than I can relate involving things like this.

Re:Yes.

[Junta]

Of course a lot of the 'medium/lows' become debates about whether they are really vulnerabilities or not. A lower severity is frequently a compromise between some security guy being surprised at a design point and a developer who intends the behavior.

But yes, the whole 'security team over here to 'fix everything', most of the software developers over there to do the work, whew they don't have to think about security because we have a team for that' is a pervasive problem in the industry.

Re:Yes.

[Anonymous Coward]

Not much of a security "guru" if you can't prevent vulnerabilities being created in the first place.

Re:Yes.

[xxxJonBoyxxx]

...said a guy who never worked in software.

Re:Yes.

[Anonymous Coward]

This.

So much, this.

Re:Yes.

[Opportunist]

You really think security is allowed in the production process before it's too late to cause deadlines to fall?

Found the guy who never worked for large corporations.

Re:Yes.

[jbmartin6]

"Fixed all"? I've worked in Security for twenty years and would never ask them to fix ALL the vulnerabilities. There's an infinite number of vulnerabilities if you look hard and long enough. Many of them are small or extremely difficult to exploit, are all of these worth the cost of fixing? At a certain point you reach diminishing returns and the stuff never gets used. However, there is no excuse for leaving obvious easy exploits in place. But I think it was Marcus Ranum who said "Security is always going to be only as good as it has to be." So until the market changes to punish vulnerabilities more, the crap will still have shoddy security. That's why I favor full immediate disclosure. 'Responsible disclosure' only serves to shield the producer from the consequences.

Liability is separated from ownership

[DogDude]

The root is that our corporate laws allow liability (for defective products, in this case) to be completely separated from ownership (stockholders). US companies can fuck customers up the ass with barbed wire, and nothing happens to anybody within the company management or ownership as a result.

Re:Liability is separated from ownership

[sinij]

I am surprised laws still treat software as 'magic'. If my new toaster catches fire and melts the counter, I can count on getting compensation from manufacturer. If my new IoT gets pwned by a canned exploit, leaks my private conversations and pictures of me dressed as a pony (don't ask), then there is absolutely nothing I can do to get damages. What the f*&k?

Re: Liability is separated from ownership

[Anonymous Coward]

God damn it. Why did YOU leak that image? Now i can't get it out of my head!

Re: Liability is separated from ownership

[Zero__Kelvin]

Sorry, but you may as well say that people keep dying of old age because there are no laws on the books against it.

Re: Liability is separated from ownership

[DogDude]

A sole proprietor in the US is liable for what they do. Small businesses are liable.

Once you issue stock, everything changes. The public corporation could knowingly kill and maim hundreds of customers, but nothing will happen to the owners of the company.

If, say, a dentist knowingly killed 124 and maimed 274 people, that dentist would go to jail, and his/her assets would be taken and wages would be garnished for the rest of his/her life.

Re:Liability is separated from ownership

[Anonymous Coward]

The difference is the hacker bogeyman. If it wasn't for those nefarious Russian hackers, the shitty IoT device wouldn't have any problems. So far, companies have been able to absolve themselves of responsibility because they can point at them. Until the law says "you should have known better", they'll continue as they have.

Re:Liability is separated from ownership

[Anonymous Coward]

Your example is bad.
If your IoT gets pwned and melts the counter then you will get compensation from the manufacturer too.

If your small time computer repair shop leaks your information or if your photo studio shares your negatives with people they shouldn't then you can sue for damages.

The problem is when a "too big to fail"-company leaks your information. Since they are above the law you can't get damages from them.
It has very little to do with the way we treat software and internet, you can't get damages even if they screw you over without using computers.
The problem is how our society views corporations and their legal position.

Re: Liability is separated from ownership

[Zero__Kelvin]

And companies aren't liable for bugs. Do you know why? Because while there is such a thing as thing as a furnace that won't explode because of its design, there is no such thing as bug free software.

Re:Liability is separated from ownership

[Anonymous Coward]

It's called LLC... A limited liability company (LLC) is a corporate structure whereby the members of the company cannot be held personally liable for the company's debts or liabilities.

Re:Liability is separated from ownership

[Anonymous Coward]

Ah, absolutely not. Management, as opposed to stockholders, are on the hook personally for a lot of things, but normally the company agrees to cover their liabilities when they get hired.

We need to share a password

[Anonymous Coward]

Our software needs password access to our servers.
I know, let's store the password as a variable in our code.
Great, how do we get the latest version of our code?
It's in the company repository.

Alternatively,
We're getting a permissions error.
Just chmod everything to 777. (Yes, I've seen this done. Yes, I know it's a bad idea).

Re:We need to share a password

[tepples]

In general, when a downloadable application needs to access a service that requires an API key, how is the application's developer supposed to make the operations controlled by the key available to the application without making the key available to rogue developers who could use the API key to impersonate the application? This is the case for the "consumer secret" in a Twitter app.

Re:We need to share a password

[Anonymous Coward]

>Just chmod everything to 777. (Yes, I've seen this done. Yes, I know it's a bad idea).

Where I work, there are roving processes looking for over permissive permissions and unpermissioning them automatically. This can
take a few seconds.

So when all the companies systems (email, sharepoint etc) are preventing you transferring your data to a colleague, the plan B is to get on the phone. Recipient types "cp ~me/ ~him/" without pressing return. I type "chmod 777 ~/" and then hit return and immediately tell the other person to hit return. If you time it right, the file will be copied before the roving permission depermissioner processes catch up.

Entirely true, I shit you not.

Re:We need to share a password

[Anonymous Coward]

Well slashdot mangled all the angle bracketed text out of that, but you can get the gist.

Re:We need to share a password

[TechyImmigrant]

In general, when a downloadable application needs to access a service that requires an API key, how is the application's developer supposed to make the operations controlled by the key available to the application without making the key available to rogue developers who could use the API key to impersonate the application? This is the case for the "consumer secret" in a Twitter app.

Welcome to Out of Band provisioning. The land of random key exchange protocols and horrendous complexity.

Re:We need to share a password

[Opportunist]

I've seen both.

In production code.

Of companies that handle very sensitive user data.

There are 3 places you should not work at if you want to sleep well at night: The sausage factory, government and security.

Re:We need to share a password

[Anonymous Coward]

I don't WORK in security.
Just as a hobby on OpenSource and care about security issues and bugs.
If I still cared, that would be enough to not sleep well.
- Even huge projects used by huge companies with deep, deep pockets do not have a security email address. Reports of security issues through other channels (e.g. public mailing lists) get ignored. Contacting random company using the project sometimes works.
- Sometimes, you come across a university project that works on discovering security issues on a large scale (e.g. when fuzzing was first coming up). You fix MOST of what they report. Sometimes with a delay that you think is really too long even though it's just a hobby project. Half a year later, you get a $100 gift certificate from a university professor "you were basically the only one to talk to us and/or fix the issues, that was so useful for our research". Someone does free testing and often debugging for you and most developers would just throw it away. Admittedly 10 years ago, but people don't change that much.

Re:We need to share a password

[Opportunist]

Someone does free testing and often debugging for you and most developers would just throw it away. Admittedly 10 years ago, but people don't change that much.

It's not necessarily different if they pay for the testing. I've seen it more than once, testing a company every year and finding the same bugs every year, only to hear "yeah, we got the obligation to test it annually for bugs and security holes".

Apparently fixing them is not part of the obligation...

And 90% of the 90% are the biggest boys

[mykepredko]

That can be simply listed as (in the order that I see them):
- Microsoft as an OS vendor (I know I'll get attacks from various ACs that think any criticism of MS is unfair but they are putting 'way more energy into sucking user's personal data into their servers than protecting said personal data)
- Large service companies with poor security for customer databases (I just saw Uber had a big hack last year that they've been trying to keep quiet).
- The 10% of so of the user population at large which don't have the intelligence to question email/text/phone/Facebook/etc. requests for their personal information.

The remaining 10% would be poorly defined standards (for example IoT) where the possible vectors and impact of security intrusions have not been thought through.

Re:And 90% of the 90% are the biggest boys

[Anonymous Coward]

Software is complex. Any non trivial piece of software probably contains a bunch of libraries that are themselves complex, and built on a best effort/time basis. At almost every stage there is the potential for abuse. Where a library appears to be secure in of itself, it may contribute to poor security when it is used in ways that are not anticipated.

Operating systems are complex. They themselves are made up of many components which are made up of many libraries, which themselves may be made up of many libraries. Security vulnerabilities may be anywhere in there, or emergent from the collective. Combining a relatively secure OS with a poorly written application which runs with user privileges may expose other issues.

Operating systems and programs often support old interfaces. That is not automatically bad, but it is yet more attack area you have to cover and eventually deprecate.

Operating systems and programs may be wrote in inherently less secure languages such as C/C++, and it may even be for good reasons, but buffer overruns may allow control of the program flow. Just get the overflow to get to your tailored jump instruction and your tailored data, which is really more cpu instructions, and now you have control.

People are stupid. People are lazy. Even smart people may not do an exhaustive search for vulnerabilities for everything they download, since well, the job needs doing, so they do the quick check and some additional reasonableness checks and move on with life. Still, clicking on what you should not is a bad thing. If you see a web page that just looks scary, power off your PC manually and don't reload your old tabs on startup. That will prevent some bad things, but not all.

Hackers exist, be it a nation state such as Russia or even the United States, or simple criminals. Some of them may even be working on obscure OSS libraries that other famous package use. I'd almost bet some vulnerabilities are deliberately introduced. I'd pretty much bet some work for Microsoft, likely from every major nation state in the world. It is hard to secure against unintentional backdoors, but even if they don't have them now, you can expect some deliberate backdoors in future updates. Hell, how do you know that phone update is of the good, and not some clandestine agency downloading a special edition?

Hardware exists with back doors, some intentional, some possibly not. Some of the management interfaces are scary as hell. Are you really sure no one is taking advantage of any of that? Silicon is usually not manufactured with say complete control of the process. Are you sure the gates AMD specified are the only gates in the CPU? (or Intel for that matter.)

COTS hardware may not get updated and even if it is, updates and such are likely a low priority. Have you plugged your smart TV in? Does it have a camera? A microphone? Do you really trust it? Is it in your bedroom? What about the gadget that monitors your kid? How an ooma really still be in business at that price? (I admit I have an ooma device.)

Re:And 90% of the 90% are the biggest boys

[Nutria]

Operating systems and programs may be wrote in inherently less secure languages such as C/C++, and it may even be for good reasons

Or bad reasons like Comp Sci elitist "I'm so smart, I'm not going to fuck up" snobbery.

Ada FTW!!!

Re:And 90% of the 90% are the biggest boys

[lucm]

Microsoft as an OS vendor (I know I'll get attacks from various ACs that think any criticism of MS is unfair

If you take a minute to look at the bulk of major incidents in the last year, it's mostly poorly configured Mongodb and S3 buckets. No SQL Server, MS Exchange or IIS in the list. There's the occasional ransomware but given the market share of Microsoft products, it's not bad at all.

Re:And 90% of the 90% are the biggest boys

[l0n3s0m3phr34k]

" The 10% of so of the user population at large which don't have the intelligence to question email/text/phone/Facebook/etc. requests for their personal information. Only 10%? You must work in a very security conscious organization then. From what I've seen over the past 25 years, I would peg that at a minimum of 50%...unless you do constant end user education, in-person reminders, etc. I've seen some pretty decent whaling attacks, complete with proper graphics, reply-to addresses (at least at first look), phone numbers, etc.

However, these aren't really "vulnerabilities", at least not software-based ones. These are wetware-based vulnerabilities. Honestly, most breaches are from unpatched systems that are improperly shielded from the net. Equifax, Sony, OMP, all of these could have been prevented with some type of patching policy, or at least correctly provisioned firewalls and IDS. But most organizations don't want to spend the money to have hardware just for pre-production patch testing, don't have working roll-back procedures, so they are reluctant to apply patches unless forced to by the apps their running.

Re: And 90% of the 90% are the biggest boys

[Anonymous Coward]

Racism aside, there is a kind of person that relies on the short term gain of delivering results, and the benefit of being seen as fast/quick/effective by their superiors. Itâ(TM)s cheating, but rarely do the higher ups ask who is responsible years after the fact. The responsible ones are long gone, having leveraged their âoeperformanceâ to climb ladders.

Re: And 90% of the 90% are the biggest boys

[Anonymous Coward]

The word "complex" covers a lot.
Computers are modular and layered. Let's look at a CPU. The actual physics is the responsibility of the chip designer. They design an electronic circuit and figure out how to make silicon behave like the circuit. Since a circuit is a simplification of the actual physics, there may be conditions where the circuit doesn't behave like the circuit diagram predicts. As an example, the diagram says that if RAM is not constantly refreshed, the content is lost. But if you freeze the chip, it can stay for a good minute, enough time to remove it and dump its content.
But the computer designer only has the diagrams and electrical specifications, and can only design using this imprecise and incomplete description. Which is good - the CPU manufacturer can totally change the innards of the CPU if they find a better way of making it, and as long as it follows the same specifications, the computer designer doesn't even need to know that they changed anything.
The software designer doesn't even need to know what CPU is going to run the software. As long as it can run the instructions written (or translate them), the software will run.
All the layers and modularity means that lots of people can specialize on just one of the intricacies of computer science without having to worry about the rest - but in the interfaces between all these, inaccuracies and unforeseen consequences can exist and compound. Cryptographic software has been hacked by measuring how much power the computer uses in each instant. Making a totally secure system requires full knowledge of all layers, which is practically unattainable in most cases.

Re: And 90% of the 90% are the biggest boys

[Reverend Green]

Honest question: why do so few companies use Ada? It looks like a pretty nice language... But I've literally never seen it in use at a private company.

Re: And 90% of the 90% are the biggest boys

[damm0]

Insufficient critical mass is probably reason #1. Why insufficient critical mass you ask? Java won users over by offering fairly easy tooling, good documentation, and an ecosystem of developers unified across Unix/Windows. It helped that Java also had a major corporate backer.

Which of these does Ada have? As far as I know, Ada's limited success is mostly due to it's use by the DoD. Not the best at spreading the love.

Re: And 90% of the 90% are the biggest boys

[Cryacin]

Succinctly put:

People think agile is about "Getting shit done!".

It turns out to be "Getting shit, done!"

Re: And 90% of the 90% are the biggest boys

[jellomizer]

When choosing which language to write code in there are the following questions.

1. Which language is popular enough to find new employees.
2. Is the language industry respected, so we don’t look like an amateur because we picked a joke of a language.
3. Does the language meet our business requirements.
4. Can I hide my code from others and my competition.
5. How quickly can it be coded in
6. Does it support modern features.
7. Can it be deployed easily
8. How forward compatible is it.
9. Is it cross platform
10. Is it secure.

That is a lot of consideration until we actually get to a secure language

Re: And 90% of the 90% are the biggest boys

[Hognoxious]

0. Will it look k3wl whan I apply for another job after I make an absolute dog's breakfast and dump it on some poor maintenance programmer.

Re:And 90% of the 90% are the biggest boys

[gweihir]

There are still people that believe programming languages actually matter for security? It is time for the dumb idea to die.

Re:And 90% of the 90% are the biggest boys

[Anonymous Coward]

There are still people that believe programming languages actually matter for security? It is time for the dumb idea to die.

Yes, program languages matter for security, since it is less work to keep a managed program secure. Can a c++ program be secure? Sure, but it is harder and is going to take more time, and possibly a better programmer. That doesn't mean we need to stop using C++, just that we need to understand the issues involved and handle them appropriately. Now, if you could do something in C# or Java instead of C++ and get more maintainable code with less work, that is almost as fast, why would you code C++ unless almost wasn't good enough or you had a latency target?

Re: And 90% of the 90% are the biggest boys

[Anonymous Coward]

I was in government software testing working with one of the original developers of ADA which was intended to design-in correctness in coding. Despite this testing is very, very expensive compared even compared to the base design and coding.

Re:And 90% of the 90% are the biggest boys

[Nutria]

There aren't going to be many null pointer dereference errors in COBOL-85 and FORTRAN-77...

Re:And 90% of the 90% are the biggest boys

[Aaden42]

- The 10% of so of the user population at large which don't have the intelligence to question email/text/phone/Facebook/etc. requests for their personal information.

You have far more faith in 60-70% of the population than I do.

Re:And 90% of the 90% are the biggest boys

[Anonymous Coward]

But I was told MongoDB was web-scale!

Re: And 90% of the 90% are the biggest boys

[jafiwam]

You forgot:

11. Which will look best on my resume.

Re: And 90% of the 90% are the biggest boys

[jellomizer]

That is embedded with #1

Re: And 90% of the 90% are the biggest boys

[jellomizer]

That is embedded with my first one.

Re:And 90% of the 90% are the biggest boys

[Anonymous Coward]

- Microsoft as an OS vendor

Might want to review your personal biases there. Some of the most critical security bugs in the last few years have been in *nix systems. All software has bugs. Microsoft is nothing special in this regard.

Re: And 90% of the 90% are the biggest boys

[Hognoxious]

Only if you write employee when you mean employer.

But then again you probably do.

Re: And 90% of the 90% are the biggest boys

[Anonymous Coward]

Like NotPetya that crippled hospitals, banks and so on?

Re:And 90% of the 90% are the biggest boys

[david_thornley]

Operating systems and programs may be wrote in inherently less secure languages such as C/C++, and it may even be for good reasons, but buffer overruns may allow control of the program flow.

With modern C++, it's easy to enforce style rules that don't allow buffer overflow. Including C and C++ as if they were the same is incorrect.

Re:And 90% of the 90% are the biggest boys

[lucm]

But I was told MongoDB was web-scale!

And the security incidents are web-scale too!

Re:And 90% of the 90% are the biggest boys

[Anonymous Coward]

- The 10% of so of the user population at large which don't have the intelligence to question email/text/phone/Facebook/etc. requests for their personal information.

10% here is a drastically understated guess. It isn't 1/10, it is much more likely to be 9/10.

Do you live in a house or apartment?

[El Cubano]

How Are So Many Security Vulnerabilities Possible?

Do you life in a house or apartment? Go around and look very closely at every aspect of the structure. As you go, make note every flaw you find, however tiny, but paying special attention to things that could be avenues for entering the dwelling from the outside even if everything is locked up. Now imagine 1,000,000 people all working constantly to find ways through those vulnerabilities without you realizing that is going on. Now imagine everybody in your city has an identical dwelling so that when one avenue is compromised, they all are.

That is how.

Re:Do you live in a house or apartment?

[Anonymous Coward]

Mica paper

Re:Do you live in a house or apartment?

[Anonymous Coward]

Except, to make proper comparison to software, one of the walls and part of the floor must be missing in your house of apartment.

I certify products for sale to the government. People that come to me to get certified expect to be scrutinized. They also know in advance what the spec is, what they must do and how. Every single certification I have done there were non-conformant implementations, half with a serious security implications.

If this is what "hardened" products for government use look like, you would be lucky if your consumer product doesn't have hard-coded admin/password123 telnet service account.

Re:Do you live in a house or apartment?

[Anonymous Coward]

Except, to make proper comparison to software, one of the walls and part of the floor must be missing in your house of apartment.

You know what house walls are made of, right? Oh, who am I kidding... no you don't.

Seriously. If your house was built in the last 30-ish years, it's foam-board and plastic-wrap ("Tyvek"), and some vinyl siding over the top of it. A broken window or kicked-in door is just a sign that those are weak points that are obvious. But never be surprised if you find a gaping hole cut in the wall and all of your stuff gone even though you reinforced your windows and doors. A saws-all can make short work of those materials and the hole size can be as big as it needs to be. Oh, and brick-work isn't any defense against this, because a crowbar can easily pry brick veneer off of the wall before the hole is cut. You're only safe from this sort of break-in if your house is masonry, and there are different weaknesses to that.

Have you ever played Minecraft on a server? Do you know that feeling when you realize that anyone could take your stuff at any time, change or destroy your buildings at any time, and generally pillage all of your stuff? Real life is like that far more than anyone likes to think about.

Re:Do you live in a house or apartment?

[TechyImmigrant]

>I certify products for sale to the government. People that come to me to get certified expect to be scrutinized.

If this is in the FIPS140 ish area, then this:

>They also know in advance what the spec is, what they must do and how.

is a fantasy.

I've commented extensively to NIST on ambiguities and architectural impossibilities in the specs and they fix some of them, but it's slow going and in the interim, a heck of a lot is left to interpretation by the cert houses.

Re:Do you live in a house or apartment?

[JasterBobaMereel]

You cannot make your house secure, unless you make it unusable as a house - same with software

Now imagine a city full of houses and realise that you do not need to make your house secure, just secure enough that it is not worth the effort to break into, and they will try and break into your neighbours houses instead ...

This is how all security works ...

Re:Do you live in a house or apartment?

[jbmartin6]

This. We routinely accept vulnerabilities in our homes, cars, lives because the risk is judged to be worth it. Windows for example. (In the walls of houses, not the computer OS). There is no reason why computerized systems should be any different. The challenge we have now is poor understanding of the risks and rapid change in the threat levels. Window-smashing burglars is a pretty static risk.

Re:Do you live in a house or apartment?

[Bender0x7D1]

Now imagine a city full of houses and realise that you do not need to make your house secure, just secure enough that it is not worth the effort to break into, and they will try and break into your neighbours houses instead ...

While a good analogy, the problem is the bad guys can write a script that will check 100k homes for the unlocked window. They don't need to limit themselves to a few houses - they check them all. So, in the end, it still comes down to you missing one "easy" attack vector, and you are just as burned as the person who has terrible security.

Irony

[Anonymous Coward]

I like how the article just previous to this one reads, "Sacramento Regional Transit Systems Hit By Hacker."

Let me think...

[Anonymous Coward]

Indians.

Next question.

Two reasons

[Luthair]

1. People aren't perfect
2. Companies chase features

Re:Two reasons

[Anonymous Coward]

>
> People aren't perfect
> Companies chase features

You need five more words ... and it's a haiku!

captcha: impotent

Re:Two reasons

[Anonymous Coward]

This! and the people have no security education, they are more than willing to trade security for convenience.

security is a problem tomorrow, convenience is a feature today. Look around, no one is thinking about tomorrow or being taught to think about tomorrow because things that happen tomorrow do not make sales today.

So to answer the ask slashdot question: money is the reason we have so many security vulnerabilities

Re:Two reasons

[Anonymous Coward]

1. People aren't perfect
2. Customers chase features

FTFY

Abstraction

[Anonymous Coward]

As compared to say bridges or ships? These can be designed with more abstract mathematics, notably calculus.

The mathematics behind software is discrete (rather than continuous as for many mechanical mechanical things), so alas no calculus. We do have some tools for discrete system abstraction, but they achieve this by being domain specific rather than a general abstraction.

This lack of abstraction is not a new problem, we just see it in the area of security because that is what is important to humans at the moment.

white hat hackers are the best programmers

[Anonymous Coward]

yes, every time i see something like this.. i go.. hmmmm.. makes one wonder..

if every who thought about or wrote a program, and that programmer was a white hat hacker we could have bliss and live happily ever after... or one could really do harm if on the dark side, yet karma is a wonderful training tool, so just wait and see..

for me, i am a white hat... ;-)

my favorite is to redirect sql injection attempts to www.fbi.gov with the attacker IP in the URL and a text string along with to say go get them...

Re:white hat hackers are the best programmers

[Anonymous Coward]

my favorite is to redirect sql injection attempts to www.fbi.gov with the attacker IP in the URL and a text string along with to say go get them...

This is the dumbest idea possible. If you start spamming the FBI, guess who's going to end up behind bars? (Hint: It's not the ones that were trying to SQL inject you.)

Re:white hat hackers are the best programmers

[Opportunist]

Simply not true.

I'm a white hat. I used to write code for a living, but that was a fairly long time ago. The code I write today is more something I whip together quickly to get shit done I need for my work. Secure? Please. It works. It probably fails as soon as any edge case comes along, let alone someone who wants it to fail.

Security is not free or an afterthought

[Anonymous Coward]

Companies treat security as something that just takes care of itself once you put a password on a site to gain access. Every company with any data has a security risk, but how many companies have a CSO? How many have a senior engineer overseeing security. Everyone is follows the big buzz words like "cloud" and "big data" and have a buzzword bingo "strategy." Not so much when it comes to bolting the doors.

Simple

[mrun4982]

Security is really hard. It's especially hard when so many insist on trying to reinventing the wheel, which countless developers do all the time.

Re:Simple

[Anonymous Coward]

And yet, IMHO most break-ins are through exploits in well-known and usually trusted third party libraries. Or code that was copy-pasted. If everyone was in fact reinventing the wheel, sure there would be problems but at least crackers would have to start from scratch for every break in.

Re: Simple

[Miamicanes]

Security is also "unfair". You, as a conscientious developer, can do everything "right", and get totally pwn3d *anyway* because of some widespread, system/platform/framework/library vulnerability (perfect example: Heartbleed).

The only way to improve the odds is for a development team to have one or more members whose ONLY job is to be aware of every thirdparty library/platform/os used by the project & literally research every single one, every single day, to become aware of vulnerabilities as they're discovered... and for projects not under active development, maintain a working build environment at all times so *somebody* will be able to rapidly build updates to the app.

You can't expect developers to do it. We don't have time to recursively scrutinize our projects' thirdparty dependencies on a daily basis... at least, not if we need to actually get any *new* development done.

I'm not kidding about the build environment problem. I have a couple of published Android apps (developed with older versions of Android Studio) that get hopelessly mangled by recent versions of Android Studio. Google has done a *remarkably* shit job of breaking old projects with no working migration path beyond, "spend several days creating a new project from scratch & manually re-create the old project in the new release of Android Studio". I've heard similar tales of woe about Visual Studio... if you're *lucky*, an old project *might* load successfully into the *next* release of VS, but if you let your old project go *too* long, it's not likely to even be importable by future releases of VS without getting mangled into oblivion. And Visual Studio sinks its teeth *so* deeply into Windows, it's hard to keep old versions of VS around (and working) in perpetuity (without having mothballed old computers with it installed), and even harder to re-create those old installations years down the road.

Back in the happy days of Netbeans, Java, and Ant, you could generally build any old Netbeans project from the commandline using its generated Ant script, even IF a newer release of Netbeans broke it. With non-Gradle Android Studio 1.x projects... good luck... but you're probably fucked. StackOverflow has THOUSANDS of questions about "how to salvage old Android projects last built with now-obsolete IDEs (Eclipse, AS1.x, etc)".

Re: Simple

[TechyImmigrant]

>The only way to improve the odds is for a development team to have one or more members whose ONLY job is to be aware of every thirdparty library/platform/os used by the project & literally research every single one, every single day, to become aware of vulnerabilities as they're discovered...

It's enough to say "Is it ok to use this library" and then tear that one to pieces. The effort involved makes the cost of writing (well) the subset of features you want from the library seem small.

Which is why I'm currently tearing apart a common open source crypto library right now and concluding that "In a cloud VM, this crypto library will get exactly 0 bits of entropy from the context it runs in". The fix is to recompile it with the right options, but the distribution build defaults in all the linuxes are simply wrong and the entropy claims in the literature that the defaults rely on are fraudulent.

It is a commonly used library and it is very, vary bad. At least there's one product that won't run into that problem.

Re:Simple

[Opportunist]

Nope. Sorry, but nope. If that was the case, the OWASP Top 10 wouldn't exist, a collection of 10 commonly made and reliably existing flaws in any piece of online application.

Anyone trying to get in would just have to try that top 10 and reliably get in. It's already bad enough with standard libs that are hardened against exactly those common problems, with everyone reinventing the wheel, we could get into any place with the standard toolbox.

Re: Simple

[Anonymous Coward]

That's why smart companies build their software on distributions that aggregate the security testing and alert of their users, instead of letting devs download random commits from github no one will ever audit and test.

Re: Simple

[Anonymous Coward]

> Back in the happy days of Netbeans, Java, and Ant

How about back in the happy days of make and gcc?
Everyone re-invents build systems because they find out they work shitty - when you don't bother to learn how to use them and refuse to maintain them and generally use them in a way that is equivalent to shitting on the floor because walking the distance to the toilet is too much bother.
Just to find out that your shiny new build system doesn't work better in the slightest if you treat it like that. It's just 10x larger, and thus 10x buggier and sometimes also that much slower. And often forgot to integrate "minor" features like support for parallel builds. I mean, why would any developer be using a multi-core machine?

It's fundamental

[Anonymous Coward]

No one cares about security.

Seriously do you really care about it either? When was the last time you challenged the lock on your own front door? You just trust that it will work because why would you? It's old tech, easy to defeat, and only serves as a request to please do not force your way into my house. If somebody wants in, they are getting in.

Same goes for software, most people implementing the security are not security focused or even experts. They only implement the security other people have provided, but if that is already insecure how can you build something on top of it that is secure?

We essentially do the bare minimum security to keep toddlers out of our system... sorry scratch that, toddlers are stumbling into them. Take a look at KRACK, discovered by accident because one security expert finally said... I wonder if I did this instead.

And to take a great well known parallel... the TSA, its all theater, and to keep that theater under control you don't make jokes, your first amendment rights are suspended at the Airport after all.

Every corner you look at in life there are vulnerability because it is just too fucking inconvenient to have real security!

I hope you know who your janitors are... maybe they are 007's in disguise. That's right, you never take notice of the people that surround you able to wreck your life the moment one of them goes off the rails. Movies do a terrible job emulating real life but they also do a good job of pointing out just how much disrespect people treat real security with! You go through life trusting that people are going to do their part and are never fully prepared for them going off the rails.

So people say they are concerned... but only so far as their liability is concerned.

Nobody cares

[manu0601]

Companies do not care about security, because they see no value in it. They rush their own developers to release software, and never ask them to focus on security.

Developers do not care about security. They never face the consequence of their negligence on it

Consumers do not care about security. They shop for the cheaper or the most hyped product, not for the one that was correctly engineered. How could they know it really was, anyway?

Re:Nobody cares

[Actually, I do RTFA]

That last point is mostly correct. Customers don't make purchasing decisions based on security, but it's not usually because of desire. It's usually ignorance. And there's no way to know which product is more secure before the breech.

Try doing it

[Anonymous Coward]

This is one of those questions you'd quickly discover the answer to if you tried to write code. Software is complicated and security is rarely the primary concern when shipping a product, and hackers have virtually infinite time after a product is launched to find problems.

Asking how software could still be vulnerable in the 21st century is a bit like asking how cars can still breakdown in 2017. It's a complex machine with thousands of parts, built on a limited budget, it's not going to be perfect.

How are so many vulnerabilities possible?

[jbn-o]

All complex software has bugs. But not all software respects your freedom to run, inspect, share, and modify the software so you can decide how to handle whatever problems arise with the software. You ought to be allowed to fully control the computers you own. Free software (software that respects your software freedom) is a means to grant people that control and treat people ethically with regard to computer software. Nonfree (or proprietary) software denies users the freedoms of free software. Nonfree software is often used as a way to hide vulnerabilities and malware; a choice which certainly hurts users. When the software's operation is a secret, users aren't granted permission to know what the program does when it runs. This means users who run such software have less control over their computer. If users aren't permitted to improve the software and distribute improvements to others the users are helpless to make their computers better serve their needs and help their community do the same. That's no way to treat other people.

It's not a matter of who writes the software (oh no, this software came from Russia or whatever other country the empire currently objects to), it doesn't matter what the software purports to do, it doesn't matter how comfortable you are with the software nor how much you paid for the software. You don't deserve software freedom any less for one kind of software or another. The development methodology is not the most important point either. The key point is that in order to treat people ethically with computer software you have to treat them as equals and let them decide for themselves how they'd like to handle running, inspect, sharing, and modifying the software. Offer bug fixes gratis (to be nice and show that you care about what you already distributed) and offer consulting services for a fee if you wish (and charge as much as you can get for your services). But you can quickly and effectively earn trust with your users by respecting their software freedom.

Simpel

[Tablizer]

Becuase humuns fowl everthing up,

Isn't it just complexity?

[adfraggs]

Computers are complex. Maybe over time we've come to take that for granted, we're so used to them. But there are many layers of technology underlying any system that's in use these days. It only takes one vulnerability in one of those layers for a hacker to take advantage. Sit back for a moment and truly consider how many lines of code (yes, machine code too) are required to enable even just the display of this web page. Drill down into every element, every piece of hardware, every layer of software. It's complex as f*c&. Making sure that every single one of those layers, every single line of code is completely unbreakable ... it's really not as simple as it might first seem. It's like building anything ... there will always be a point of weakness. The strongest steel in the world can still be broken if you apply enough force or if the manufacturing process allows a flaw to creep in. Nothing you make is ever completely and utterly unbreakable, and that goes equally so (if not more) for IT systems that are build on platforms that other people develop before you. Apply that across your multiple layers of hardware and software and there are probably an unlimited number of ways in which a system can fail. For me the question is fundamentally wrong. I would ask: "Why don't we all understand that security vulnerabilities can never be eliminated?"

Disposable people

[Anonymous Coward]

Another aspect I think matters is how management at these companies treat a programmer = a programmer and make people disposable in layoff rounds. They lose all kinds of expertise and team synergy that can't be quantified and the replacements even if they're just as good will take a long time to get up to speed and the previous code/knowledge, them thar be dragons... (don't touch ANYTHING!)

Who asks stuff like this? No one who's seen code.

[engineerErrant]

Please, before you post on Slashdot about code vulnerabilities, make sure you have at least programmed a "Hello, World" before. This post reminds me of the time a frustrated boss demanded to know why the game AI I was programming didn't "just use common sense."

More vulnerabilities are happening because there is a *massive* increase in software in consumer products. A bazillion products now have codebases that didn't before - ovens, toys, even my damn Christmas tree. Combine that with professional and social media that's always looking to dredge up outrage, and an increase in bad actors who realize that public outrage can work in their favor, and boom! You have a constant stream of stories about security holes. Why is that hard to understand?

Engineers are increasingly educated about new security threats - we evolve much faster in dealing with new challenges than almost any other type of worker. But yes, things get through, because this shit is hard - much harder than clueless internet whining. Also, because we're on the front lines of two wars - against those who tear down what others build, and against those who squelch innovation to preserve their own fat-cat positions - that is exponentially more intense than it was even a few years ago.

Expect the future to get *much* bumpier than this.

Unavailable: Principle of least privilege

[ka9dgx]

Almost all security problems boil down to the absolute lack of support for the principle of least privilege. None of the commonly used systems have anything approaching this concept. The crude approximation available is to put each resource in a virtual machine and tightly limit its connections to other virtual machines that need to access it for a specific resource... then watch those like a hawk for traffic spikes etc.
The other thing that could help immensely is to install Data Diodes, which are gateways specifically designed to NEVER let data flow in the non-desired direction, guaranteed by physics. The come in pairs, they have a normal network connection on one side, and one of the pair can only transmit, the other can only receive, usually via a single fiber.

This stuff can be fixed, I've been saying so for at least a decade now (go ahead, search my comment history here and elsewhere)... ya'll are slow on the uptake. I figure another 5 years before it starts sinking in, and at least 10 more to get it done.

Re: Unavailable: Principle of least privilege

[Zero__Kelvin]

Wow, that was some seriously stupid shit. I can only hope that was supposed to be a joke, but assuming it wasn't: Behold! People like this are often involved in the development process. That alone is enough to show you why.

Re:Unavailable: Principle of least privilege

[Anonymous Coward]

LOL at the guy that thinks most security problems are technical problems instead of the result of perverse risk prioritization in response to market demands.

Re:Unavailable: Principle of least privilege

[Anonymous Coward]

would you go so far as to say you know how to "make software great again"?

Re: Unavailable: Principle of least privilege

[ka9dgx]

You've taken a shallow view of this... like some one who thinks that circuit breakers aren't necessary, it's just the users of electricity who aren't careful enough. Limiting the scope of change that a instruction can execute is the primary job of an operating systems, and Linux, Windows, and all the others just can't do it. Capability based systems provide safety, in a user friendly and transparent way... just like the breaker box in your house.

What we have now, is electrical equivalent of a power grid without breakers anywhere... imagine if every circuit in your house could potentially have megawatts flowing through it. This is as close as you can get analogy wise to having a stack or buffer overflow that can be exploited.

It's a very deep design flaw, it takes a while to sink in.

Re: Unavailable: Principle of least privilege

[Zero__Kelvin]

First of all POLP is not new, and saying that no IS has anything close just shows what an idiot you are given that you say you have been. Involved in computing for a long time. Second your solution, even if it made a modicum of sense, is fundamentally no different (try to be secure and watch the system like a hawk) than what it is now. Your little "data diode" thing is probably the most stupid thing I've ever read on Slashdot (literally). Might I suggest you persue opportunities in the janitorial services?

Re: Unavailable: Principle of least privilege

[Anonymous Coward]

The US Military uses data diodes every day. I can tell you with 100% certainty that every combat plane and nearly every commercial plane you've ever seen has had its test data shuffled through at least one. I know. I test them. Just because you don't know what the fuck a data diode is doesn't mean it's a piece of shit. L2Google n00b.

Re: Unavailable: Principle of least privilege

[Anonymous Coward]

Holy shit. That is a serious disinformation op there! You must be CIA. :-)

for fucks sake ...

[Hugh Jorgen]

the stupid fucking cute and oh so thought provoking bullshit ... take the domain off auto-renew. let it die. /. yesterday's news today! yay!

It's the hippies!

[cwsumner]

It's mostly because of the hippies in the 1960's and 1970's, who believed security was a government plot and "Data just wants to be Free!!".

Many people were influenced by this attitude and often don't even know it. The result is:

"If Engineers built buildings the way Programmers write programs, the firse woodpecker that came along would destroy civilization!"

If you don't always check for error return values, then this is you... 8-}

Re:It's the hippies!

[Anonymous Coward]

If Engineers built buildings the way Programmers write programs

COBOL code will still be running long after the devloper's office building is torn down and forgotten.

If you don't always check for error return values, then this is you

You're still using a language where it's necessary to check for errors? You're the one making a house of straw.

Re:It's the hippies!

[Anonymous Coward]

Passwords suck. Why do ppl want to limit access to information? It's controlling.

Re: It's the hippies!

[Anonymous Coward]

Well played sir

Wont change until theres consequences

[Anonymous Coward]

When people go to jail for endangering other citizens it will change, until then this is how it is.

Re:Wont change until theres consequences

[Anonymous Coward]

What is the real danger? The companies have insurance to pay for breaches. It's like banks set aside money for fines when they are caught manipulating prices in chatrooms. If we didn't harp on scarcity of money and credit ratings and absurd, arbitrary credentials all the time, we wouldn't need to worry about identity theft.

Nobody gives a crap...

[Anonymous Coward]

...that's why.

1. Planned obsolescence.
2. The customer is very often the actual product for the big players.

After this point I'm just going to start making shots in the dark...

Nobody has any faith in the system anymore. Or if they do. They don't really care about what they are doing. What do the hardware/software people get out of the deal? Couple that with the fact the top dogs WANT insecurity built in as a feature for them.

Really truly, aside from all that... My friend told me a story many years ago now. She had a friend who was a Drug using fella (nothing wrong with that in of itself, IMO) who would go around scrapping copper for extra dosh. He didn't just go after scrap copper, though. He would go after the grounding lines for telephone poles. This is the kind of (behavior) that is just a symptom of our entire culture. The real wheels that are spinning things are often lubed up by this sort of behavior.

Security in the internet of things? It used to be an internet of the people by and large, and we are losing that, and now these, "things", suddenly matter? Hell no.

Some homes in the world don't even have locks on their doors. A friend of mine was one of them. I walked right into their house one day to see if they were home and they weren't. The thought of stealing some money even popped into my mind. I didn't though. Why would you steal from a friend? They weren't home, so I left.

Nobody gives a fuck about securing shitty products that do shitty stupid pointless things touted as miracles in a country where a high functioning socio-path named steve jobs is regarded as some sort of savior. Mean while we look at some one like RIchard Stallman as some sort of nut jub, when in reality his only real crime is probably just being a goody two-shoes and giving a fuck about something other than convenience (ethics, liberty, and such).

Nobody at these mega-corps gives a fuck. And even if they do actually have a spiritual connection with the work they do, or even just find value in what they do, how in the fuck are they supposed to do their job when they have to have military grade fucking security just to keep the cogs turning and greased up? It's insane...

the people can't effectively govern themselves anymore cause their is barely anything worth governing anymore to begin with. I don't mean the U.S.A. or elsewhere is in a state of anarchy. It's just that... The resolution of society is so high and sharp anymore, the weight of each individual pixel/person is so miniscule it's hard to appreciate the actual constitution of the image as a whole.


how hard would it be for the most advanced military in the world to just crack every damn business they could, then use that as a means to sell them better security? It's like picking our pocket and selling your own watch back to you. Palms get greased and security goes up.

nobody cares about that crap they are making/selling, cause it's all absolute shit to begin with...

we can inject nano particles and change DNA... but we can't create a car sturdy enough to last 20/30/40 years? We could, nobody wants to put themselves out of business, though. Maybe, there's better things to be doing than business and a lot of people just don't know what that is yet?

(I'm pretty sure making love is one of them, though. That's a start, maybe. Nothing comes in at a close second, perhaps.)

If you look at how powder Drugs are sold on the black market. They usually come from the source rather impure to begin with, then it's just cut-in, sold to the next guy, cut-in, sold to the next guy, all the way till the customer is reached. Well when that chain gets long enough, the customer ends up with nothing but cut-in filler and no drug. And if they know their Drug well, enough, they'll know they got sold baking powder. And that the only thing left anymore IS baking powder.

VERY easy answer

[Anonymous Coward]

Management: Why hasn't it been released yet?
Development Team: Because it's not finished yet
Management: Well we promised XYZ partners that it would be released by now
Development Team: You promised who WHAT?!?!?!
Management: Have it ready by the end of the week
Development Team: We have many weeks work left, AND THEN we have to have it go thru Cyber Testing
Management: Cyber-whats-it? That testing is only going to cost us money and put us behind schedule even more - skip it and ship it - NOW!!!

And they you read moronic articles about how developers should be held accountable when the shit hits the fan.

If you use Cloudflare for the receive server,

[Anonymous Coward]

then you don't care about user's privacy.

https://github.com/mozilla-mob...

The rot starts at the top

[Anonymous Coward]

Dominant companies set the scene by having designers that produce rubbish designs. Then you have a race to the bottom by managers and coders not understanding the designs, knowing bugger all about the problem domain, and thinking that whatever pap they get running (and this as soon as possible) is fit for purpose.

Here's a couple solid reasons why... apk

[Anonymous Coward]

1.) Feature-creep (adding "new hotness" & not checking it well OR thinking it thru completely as to what might be exposed) & it can LEAD to-> 2.) BEING TOLD BY MGT. "GET IT OUT THERE NOW & DON'T WORRY ABOUT A BUG WE CAN PATCH LATER" (this happens & it infuriates devs (did me) but it has SOME merit in a sense - I was told, point-blank, that IF/WHEN a bug's intermittent (usually caused in my experience by data that was 'malformed' (keypresses & filtering beforehand stops this & SO DOES DBA's CREATING VIEWS) 9/10 times & not so much the code itself) ISSUE THE CODE, patch later (usually 'later' never comes like performance tuning in an industrial environs UNLESS users complain).

* I'd be WILLING TO BET that other devs here have seen those 2 scenarios - I know I have (retired now though for 10++ yrs.)...

* That's just "in general" scenarios - now, on security SPECIFICALLY? The "cracker/hacker" types ARE GETTING STRONGER (by far) nowadays - for instance/e.g. - whitelists (sometimes thought of as 'superior' vs. blacklists like hosts/firewalls) = EZ TO BLOW BY (do it by hiding underneath another LEGIT allowed process (as a lib/dll)).

APK

P.S.=> Sometimes it's "rookie devs" too but that just "comes w/ the territory" (or rookie DBA's too) - it usually changes once you learn more from "seasoned pros" (I know I did - I was lucky to be surrounded by GREAT ONES in my career & other arenas in my life, like sports in the NCAA too)... apk

For every lock, there is a key.

[Anonymous Coward]

If you can use it, somebody else can figure out how.

Thought experiment

[Anonymous Coward]

Thought experiment time:

You are the manager of a small (read: limited resources) software company deciding how to spend your engineering hours for the next release. A group of potential customers have decided that features X,Y, and Z are very important to them. If you choose not to implement those features you are unlikely to win that business. Security fixes will not win you any sales and 99% of the time will not lose you any sales. To make them you have to give up X, Y, or Z.

Decision time!

The fix should be obvious. Make this business's customers care about security. Being hacked needs to be more than a minor one time cost on a quarterly balance sheet - it needs to be devastating. Hoarding vast amounts of data needs to become a liability, and the decisions to keep around something so radioactive should be approached with careful deliberation. Insurance products should emerge, complete with security audit stipulations.

There are likely lots of ways of doing this. The most obvious to me is to put some serious legal/financial liabilities on leaking data. Unfortunately, I expect doing this suddenly would cause economic turmoil as companies everywhere scrambled to harden their systems. Companies with more resources are most likely to have a head start on this already and may not even take a profitability hit. Many small companies would likely be put out of business completely, as the above thought experiment shows.

Because it is hard, and sometimes not possible

[Harlequin80]

Security is not free. It is neither free in that it requires lots of man hours of time to develop & code, and that security has no impact on the user experience.

You can do end to end encryption of all traffic, encrypt at all states, require multi-factor auth, require physical devices, require secure portal software. But all of these have operational costs as well. But in the cost of compute and in the usability of the software.

If you had to access gmail through a specific secure application, with 3+ factor authentication, and it was really really slow, would you use it?

Not real engineering....

[Anonymous Coward]

There is no system of professional licensing, etc for so-call "software engineering" like there is for say, civil engineering.

When shit goes wrong no one is responsible.

We need to treat our digital infrastructure just like our physical infrastructure. For critical projects, someone should be signing that the code has been written and reviewed using industry-standard techniques, just like there are industry-standard techniques for designing a bridge or calculating the margin of safety on an AMSE pressure vessel.

It's time for large sections of the software industry to grow up from the do-whatever-we-want era of the 70s and take responsibility for being a critical part of peoples lives, just like civil and mechanical engineers did 100s of years ago.

The Mechanism Of The World

[NicknameUnavailable]

Aptitude doesn't get ahead, it doesn't lead to controlling resource allocation, it doesn't lead to making great things.

Social skills and willingness to take risks while simultaneously being blind to the potential consequences yields wealth, which controls resource allocation, which makes shit things.

We have a fundamental issue with the nature of our societies which prevents us from having nice things, no amount of PM or skill can change this.

I'm not saying the least suited for wealth will always have it, but the most suited likely never will given our current methods.

They don't know how to cost-effectively. Locksmith

[raymorris]

I think most companies don't know how to produce reasonably secure software cost-effectively. They aren't motivated enough to spend a ton of money on security. So they give up on trying all that hard, to varying degrees.

Some companies try educating programmers a bit about security. That's good, but not sufficient. Programmers are constantly learning new frameworks, new libraries, new languages, new systems they have to integrate with ... They aren't going to be security experts too.

In my experience, the main cost-effective way to improve security is to have a security professional consult with developers at three points in the process of a software project. Then integrate part of what's learned into automated parts of the DevOps build and release process. One hour from a security person at each of these three points can really make a difference, not only in the current project, but in future projects. Have the security person join a meeting and be part of the discussion at these three points:

The initial overall design / architecture
        This will allow the security professional to point out spots where security issues commonly occur, "be sure to use TLS (ssl) for this connection". It will also catch major architectural decisions that lead to big security problems that are very hard to fix later (such as an ISP planning on managing customer modems over their public IPs).

Finalizing the design details
    Similar to the above, but at a finer-grained level

Pre-release testing and approval
      Around the time you're starting integration testing, your security person can review the implementation based on notes they took in the two earlier stages. For some of these code-level things they can add to your existing pipeline, so from then on Git will warn you immediately when you try to commit code that follows a dangerous pattern such as use of std::process::Command with variables influenced by user input, or improper reuse of mutable buffers. (Here I use Rust terminology, the same errors can be made in most languages. Few bugs are langauge-specific).

Not only will this catch issues in the current project, but everybody learns from the interaction in order to avoid creating similar problems in the next project. Instead of studying 2,000 pages about security, the developers are being made aware of the specific issues that they tend to create in the specific domain the company is writing software for.

This process allows one security professional to effectively serve many programmers on many projects, much like your database expert might work with developers on many projects. You can get a lot of security improvement for not much money.

* Before somebody says "2,000 pages is ridiculous. Security is easy, all you need is the OWASP Top 10â, I'm a member of OWASP. I know very well the quick "rules of thumb" we publish. I've personally read over 10,000 pages about security and I don't know anywhere NEAR all that there is to know.

How?

[Anonymous Coward]

From TFA summary: [...] "How, in the 21st century, is this possible, and with such frequency?" [...]

Answer: Human Malevolence.

Quantum computers.

[wolfheart111]

Computers are still pretty new. Quantum computers should fix the problem ?... maybe... :)

Several things ...

[Anonymous Coward]

There's a bunch of reasons:

1) Code complexity -- nobody has a fucking clue what all is happening with code because it's built on a shit pile of abstracting layers because the devs can't do anything without training wheels

2) Devs are human, and lazy -- and after more decades in the industry than I care to count, "works for me" is far too frequently still what developers say

3) Companies are cheap and deadline driven -- they don't care if there's bugs, just ship the fucking thing on time and ensure we have a good quarter

4) Companies don't give a fuck -- between the EULA you signed, and cutting costs, security is at best a secondary priority

5) The gazillion monkeys which is the internet ceaselessly try everything, and in some cases exploits are just a kit you buy on the darkweb (you all remember script kiddiez don't you?)

And probably a whole lot more I can't easily summarize.

In a world driven by the almighty quarter, and the almighty marketing machine, and ran by people who have no personal liability except their quarterly bonus ... the fucking name goes on before the quality goes in as long as it ships on time. From the PMs all the way up the to fucking CEO, as long as it ships on time and you can tell a good story to the shareholders for this quarter, not a goddamned other thing matters.

Many many years ago, software was smaller, programmers were much more intimate with what it did, there were way fewer threat vectors, and people had the time to release good and stable software because you couldn't just whip out a patch and download it; these days it's all about releasing a version, booking revenue, and we'll fix security issues later.

Only there is never any time, resources, or money later to fix the shit you did several releases ago, because you're too busy adding more pointless features and security holes for the next release. Because management says so and because they don't give a fuck about something as boring as fixing bugs and optimizing code.

Good software has become un-glamorous, because nobody has the luxury of spending time on improving what you have, just slapping on whatever buzzword du jour and shipping it.

Why are there so many security vulnerabilities? Greed, laziness imposed by greed, incompetence imposed by greed, laziness not imposed by greed, and incompetence not imposed by greed, and way too many fucking moving parts for any one person to have even the slightest idea of what all the pieces do.

Some of the worst programmers I've ever met can't do anything without a framework, library, toolkit, or structure to help them build it -- and in many cases, they simply wouldn't know how to implement without someone having done most of the work for them.

There's a place for frameworks, but there's also a place for people who can write code without relying on them, or who have at least done so enough so as to understand what they're actually doing instead of relying on someone else to have done it.

humans are the weak link

[Anonymous Coward]

Even if everything you say is true and even if all of those things are fixed, you cannot fix the bugs in the human brain that allow them to give up secrets. There has to be human trust somewhere and it can always be abused.

The stuff you talk about is all necessary of course, but the humans who are running the show will always be corruptible and they will always be corrupted.

So your advice is only half-baked because you don't really mention any plans for what to do after your data is gone. It's going to happen so you should figure out what you will do when you discover a breach. Do you just pull the plug on your internet at once? Do you know how to do that? Do you tell the cops? Do you call your insurance company? Do you call the press? Do you even know who to call? Crickets from the high-paid consultants.

Customers won't pay for security

[DidgetMaster]

Company A builds product X. They design it with security in mind. They code it with security in mind. They test it a dozen ways from Sunday. They are constantly trying to break it and fix it every time they can. They want to charge $20 for using their software to recoup their investment.

Company B builds product Y that directly competes with product X. They give security a passing interest. They throw together the code and ship it as soon as it works in 90% of the cases. They don't bother testing. If a bug is reported, they might fix it in 6 months if they get around to it. They want to charge $1 or give it out for free.

Guess which product almost everyone chooses? Can't say I blame them all that much because it is nearly impossible to tell which product really is more secure when you buy it. Software companies will begin taking security really seriously when customers won't buy it because they didn't. Maybe we need something like Consumer Reports for software.

Re:Customers won't pay for security

[djinn6]

Even Consumer Reports can't tell if a piece of software is secure. In fact, nobody can tell you whether it is secure. They can only find vulnerabilities, and if they have access to the code, whether code quality is good, which may or may not correlate with security.

I think this is a case where the market breaks down, because no matter what the consumer does, they have no information to judge a product's security with.

Everything is [inherently] broken

[tanstaaf1]

Most programmers think code can be made secure if they only have better compilers, debuggers, or follow better practices. They are fundamentally mistaken about the nature of the problem.

This article lays out the nature of the error far better than I can. Please read it and then THINK:

https://medium.com/message/eve...

And then consider: âoeIt is difficult to get a man to understand something when his salary depends on his not understanding it.ââSâ"âSUpton Sinclair

Re:Everything is [inherently] broken

[wiretrip]

That's a great article! Thanks for the tipoff :-)

Re:Everything is [inherently] broken

[Anonymous Coward]

great article, thanks

Make a list

[AHuxley]

Management. Costs of security takes away from their pay, shareholder value. Thats less jets, holidays, gambling, yacht time.
The security services want an easy way in they can use the cover of average malware for.
The police want a way in so they have contractors hide as malware.
The security services and police need a way out of a system, network with the data they find.
The method used by police, contractors, security services finds its way into the hands of cult, faith groups, criminals, the media, ex, former police, political groups.
Lots of groups, people have reasons for wanting to get into another network, computer.
With the funds to buy methods, the data moved looks like the action of malware or a protected US police investigation https://en.wikipedia.org/wiki/... . Code litter is left to show its just malware thats been seen before or the work of another nation (Marble Framework).
Big brands have to be ready for existing or future lawful demands by nations, their security services. PRISM ready.
https://en.wikipedia.org/wiki/PRISM_(surveillance_program). That open door, trap door, back door lets a lot of other people, groups in once secret Police/mil/security services methods get passed around, sold, rented, given away, shared with people of the same faith.
So what is/was the ANT catalog keeps working https://en.wikipedia.org/wiki/...

The cost of creating a secure system is often in management, lawyers, compliance to US, UK, EU laws.
Some money then has to be found to code the network, service, system, OS. Low cost workers are found, the final gov/mil paperwork is the only part that has to be worked in the USA, UK, EU.
Quality slips, the police/mil/security services back door, trap door, junk encryption, extra keys then get handed around.
Too many people in too many other nations have seen the easy way in.

Another part is corruption enquiries. Police, mil, special forces who are doing a good job need to be able to collect on bad contractors, the judiciary, organised crime, politicians. If the networks are too good its hard work to secure global collection on a nations corrupt officials.
Everyone has a good reason for a trapdoor, backdoor, junk encryption, poor standards, rushed products, police support.
Malware and criminals, faith groups, cults, the media, skills people just follow the networks left wide open.

The mil also likes plain text networks as it made sending raw data globally much more easy. The network was secure from collection to sorting at a secure base.
Plain text stayed as the method to work with and then contractors got to sort data away from a base, secure site.
Gone was the physical site security of the 1960-1980's and contractors now have data in plain text on networks open to the internet.
Plain text is all they are allowed to work with but their own network security is junk or was never set up with any skills.
Plain text also allows the clandestine agencies to search many different US wide networks to find skills and staff with clearances they need.
No need to ask for a key, say why or have searches questioned. No new Iran–Contra https://en.wikipedia.org/wiki/...–Contra_affair questions later, no looking over crypto use logs.

The removal of union staff on site saw an expansion of networks to cover what staff on site had to look after. More new remote site networks got left wide open.
Nobody wants to pay for their own secure networks to cover a city, state, part of the USA so that new low cost "internet" was used as a very secure network.
Years later that consumer OS, junk network get found by skilled people, groups mapping every network their area.
Obscurity did not work years later with no upgrades.

Watching staff. If networks are too secure how can staff wi

Priorities

[durdur]

I know quite a few CEOs and VP level execs. They are very focused on revenue. They are spending all their time trying to land new customers and grow the business. Security is a cost: generally: you have to pay money for it, either to security vendors or in headcount, and there is no corresponding revenue that you get. So it goes to the bottom of the priority list. Somewhere in their heads they know that deferring it is a bad idea, and the cost of a security breach is something they don't even want to think about, but there is always a new revenue target to hit, another customer to land, etc., and so the security stuff get put in the "maybe later" pile.

It's not glamorous

[Anonymous Coward]

Let's be honest here, its no secret that security is not glamorous. As the guys with money start to realize their customers deserve better and to avoid lawsuits, they will invest. But that's just a start.

Let's be honest here, I cant work on the same coding project my whole life, and frankly, go for it, design and develop until your hearts content, develop away my little minion, you wont be able to stop everything anyway. This does not mean you should not try, and try you must, but realize if someone wants your car, they will get it.

Was it created by humans? Then chances are it will be broken by humans.

Its hardly just a software or hardware issue, its humans.

as a software engineer

[Anonymous Coward]

As a software engineer for 15 years and project manager for 3 I can explain it simply: we're fuckups and nobody pays check on us to make sure we're not fucking up.

Addendum (faulty 3rd party libs/toolkits)... apk

[Anonymous Coward]

See subject: Use of faulty 3rd party libs/dll or toolkits - a fault developers using others' libs & faulty libs devs!

E.G.-> A competitor to APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ in Hostsman (doesn't do as much as mine ala hardcoded favs you spend MOST time @ online speeding them up via FASTER local RAM access vs. remote DNS + protects you vs. DNS security issues or DNS down & dns requestlog trackers - they used SQLite (browsers do too) & IT TURNED UP A HUGE BUG!

I was asked by Malwarebytes' Steven Burn "Why don't you just use SQLite & be done w/ it?"

THIS IS WHY!

I wrote my code myself by hand (never a bug in that program above to date since 2012).

APK

P.S.=> Depending on OTHERS WORK weakens you not coding a job yourself (you have MORE CONTROL of it via source you wrote yourself totally)... apk

It's possible to fix.

[Anonymous Coward]

Speaking as a secure software expert, you can develop secure software. Doesn't mean it's easy though!

Why is it hard? Performance and security is hard. The only language that provides both is C++ and that's only if you use the advanced features.
Libraries are in general shitty due to lack of security management.
What we need are "security manager"s, "security auditor"s, and "security scientist"s in addition to programmers. A security manager would oversee software development from an architechtural viewpoint and manage the software developers/patches. Security auditors would review new code patches for vulnerabilities before submitting thier opinions to the security manager. Generally each patch would be independently reviewed by at least 3 security auditors, and the manager would be able to draw conclusions from the opinions of the three auditors. A security scientist models the threat model that the application is designed to protect against and develops the practices that the code base needs to follow in order to be secure.

Backdoors

[Stan92057]

IMO they are back-doors they don't want closed. Look at adobe flash how many holes have been patched over the years. Windows, them too and many more So ya back-doors they don't want to shut. Too much data they want to take that has nothing to do with making their products better. But will make them plenty of money

Re:They don't know how to cost-effectively. Locksm

[l0n3s0m3phr34k]

"Does it compile? Then it ships!" per-quarter profit margins demand it!

Two reasons

[aaarrrgggh]

Laziness and Usability.

Usability really comes back to laziness most of the time.

The other obvious issue is that the chaining of independent "design compromises" is often what leads to full blown compromises.

Security also not fixed by money...

[Junta]

Often companies make 'security teams' that go in and tackle the security problems so the other developers don't have to. This helps with things like, say, bundling third-party libraries with known CVEs, and answering security concerns *when the developers bother to think to ask*. However, so long as your rank and file developers don't think about security and how an attacker would go at their code pretty much all the time, there's no way a security team is going to be able to keep up with the 'organic' code, which contains many design decisions that no one even thinks to bring up for security review.

Re:Security also not fixed by money...

[phantomfive]

However, so long as your rank and file developers don't think about security and how an attacker would go at their code pretty much all the time, there's no way a security team is going to be able to keep up with the 'organic' code,

You can say that again. As long as programmers have power to write turing complete code, they have power to write security vulnerabilities.

Laws of physics/materials don't change

[Anonymous Coward]

Laws of physics or materials don't change (for mech engineers) - things change in computing like mad by comparison

E.G. - As new gTLD's were added, it made ME have to go & add them to my code for APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ to test endings of lines in hosts for VALID tld - otherwise remove it & MINUS me doing that, my program would have missed a TON of malicious sites on new gTLD's (many have $1 price for domains w/ 255 subdomains beneath 'em - gTLD WAS ATTRACTIVE TO MALWARE MAKERS more than ANYONE!) & gTLD busted a LOT of others' code!

APK

P.S.=> No bug's turned up in my program to date since 2012 but I wrote my code myself not using 3rd party libs/dlls (All per my point here https://ask.slashdot.org/comments.pl?sid=11386999&cid=55600479/ I noted as a 24++ yr. professional dev. )

Not validating your inputs is a big one...

[Anonymous Coward]

... which includes sql injection, buffer overflows, and lots of other problems.

Security is the cost of "hitting the window"

[Ungrounded Lightning]

Companies do not care about security, because they see no value in it. They rush their own developers to release software, and never ask them to focus on security.

It's not that they don't care about security (although they often don't). It's because, in the competitive environment, the "invisible hand" separates the companies into "The Quick" (pun intended) and "The Dead".

For each new computer-based market opportunity there are typically far more companies trying to get to product than there are niches for them. The first one, two, or three will get through the "window of oppotunity" and take the market, and the rest will be left out when the window closes - perhaps to die, perhaps to move on to some other opportunity, rinse, and repeat.

To get through the window before it closes, development has to be fast. Something has to give, and practically EVERYTHING that gives makes security holes. So the Pointy Haired Bosses tell the workers to get the product to market and THEN worry about fixing the security holes.

Some of the developers make things secure anyhow. Most of them find the window closed when they're ready to ship, because the ones that did what management told them already got to market with the features working and the infrastructure made of swiss cheese. They took the whole market - before the bad guys discovered the holes, exploited them, and the media finally noticed.

Re:Security is the cost of "hitting the window"

[Anonymous Coward]

Did you just prove that the "invisible hand" makes everyone worse off?

Re:Security is the cost of "hitting the window"

[micahraleigh]

Did you just prove people who don't like the market think they understand better than everyone else and want to become tyrants?

Re:Security is the cost of "hitting the window"

[manu0601]

Many western countries, including US, have been regulating markets with a heavy visible government hand during the post WWII war. They did not turn into tyrannies.

Re:Security is the cost of "hitting the window"

[manu0601]

So the Pointy Haired Bosses tell the workers to get the product to market and THEN worry about fixing the security holes.

Unfortunately, even products that are well established and protected by a network effect (e.g.: Adobe Flash) still ship will many security holes.

Re:Security is the cost of "hitting the window"

[micahraleigh]

Consider the NSA is broadly scooping up all communication in a broad warrant, the IRS has been auditing based on political views, the EPA has been crucifying people based on unlegislated regulation, and the NEA has been using federal funds to promote the presidents agenda ... would you consider the US a success at not turning into a tyranny?

Re:Security is the cost of "hitting the window"

[manu0601]

I wad referring to the post WWII war (1945-1971) era.

There are no stupid questions... I guess

[frank_adrian314159]

... but the one posed by the article's title comes close.

Given that most widely-used OS'es start from a base of languages that are not secure with manually-managed memory management, that most OS and application programmers are not (and I'm being charitable here) security experts by any means, and that software processes to mitigate these issues are still often pushed aside for "business" reasons when not deprecated in the name of agility, a better question is "How do we turn out software that stands up so well to constant battery?" The answer lies in oftentimes heroic actions on the part of a software team as well as endless iterations of testing and defect fixes. Neither set of actions is particularly transferable or scalable, but with constant influx of cash from customers for whom insecure software is better than no software at all and a constant flow of fresh programming minds, they are certainly and sadly sustainable, which is why such practices persist.

*most* code wasn't written in the 21st century

[Anonymous Coward]

If you look at the code stacks, you'll actually see that *most* code wasn't written this century. (OSes, libraries, toolchains, lots of production applications)

We as programmers build on the work of those that came before us, *most* programmers these days don't understand security and it's the best we've ever had:

'70's: "Wow look, it printed Hello, World"
'80's: Hey we got those two completely different systems to talk to each other over a serial link (or token-ring if you were really unfortunate)
'90's: Hey neat, vendor X is now supporting the IP stack, I can now contact one of the (small number of) servers on the internet
'00's: hey someone is port scanning my system, I'll block them, maybe think about a firewall
'10's: [management] "deploy, deploy deploy", WTF am I getting hacked every 5 minutes ?????

Cost vs. revenue

[Todd Knarr]

Because security is a cost center while new features are a revenue center. The executives who ultimately decide priorities, budgets and schedules are taught to minimize costs while maximizing revenue. The results are, obviously, highly predictable if supremely disappointing.

Bloated object oriented and interpreted languages

[Anonymous Coward]

There I said it. It allows for lazy programmers who have no clue what they are doing.
  Java, .net, python, rust, and the list goes on

Buffer Overflows - program testing cost too much

[Trax3001BBS]

This was Microsoft's stand for the longest time, it cost too much for the extra time it took to test.

"It all comes back to one programmer being careless," Paller said. "You wrote a program, asked someone for input, gave them space for a certain amount of characters, and didn't check to see if the program could take more. You are incompetent, and you are the problem. One guy making that mistake is creating all the work for the rest of us." https://www.cnet.com/news/stud...

Re:They don't know how to cost-effectively. Locksm

[phantomfive]

The sad thing is "doing it right" doesn't take longer and can even go faster. An easy example is SQL injection attacks: use parameterized queries, and you have no problem with them. It takes no extra time to do that, and it eliminates the attack vector.

I forgot the other part, the locksmith part

[raymorris]

Another thing to think about to understand it is that for thousands of years, people tried to make secure locks; every time locksmiths figured out how to open them - pretty easily. Security is very hard. Offline, it's okay that Pop-A-Lock can open your lock for $20. That's the accepted level of security.

Online, people thousands of miles away can use computers to try to crack the security on tens of thousands of victims, while the attacker is sleeping. They don't need to be skilled attackers, they just get hacking tools (software) from the relatively few people who are skilled. Popular web sites can be attacked a thousand times per day or more. Not even Chuck Norris can fight off a thousand attackers every day and never lose. On the WEB security is very hard. You MUST have layers of security, because somebody will break through the first layer, and the must have well-disciplined operational security.

* Medeco has finally done a reasonably good job of making physical locks that are hard for a locksmith to open. Not impossible, but hard. Breaking a window is still as easy as ever, though.

Linus Torvalds

[Anonymous Coward]

and his fan boys think that security is something that just happens after you fix enough bugs. They ignore the fact that no software has ever been bug free and it only takes one obscure security bug to make a program insecure while one regular obscure bug is irrelevant to the overall quality of a system. So rather than give up a few percentage points of performance to neuter whole classes of security problems, they play whack-a-mole one bug at a time. They have already given up performance by writing in a semi-high level language like C, but that was mostly to make it easier for them to develop new features. Preventing potential security bugs from ever being a problem, doesn't get them either fame or fortune.

Admittedly, Linux and its benevolent leader organizational structure is fairly unique as far as software development is concerned, but the attitude that security is just the result of fixing enough bugs rather than careful design and use of appropriate tools/methods is fairly widespread. Plus the lack of any incentives to spend time on security or give up any potential performance is also pervasive.

Unless attitudes (incentives?) change, we will continue to see a long stream of problems.

Because nobody knows how to code

[Khyber]

Instead you rely upon languages to handle the safety and optimizations your lazy ass couldn't be bothered learning in the first place.

And you wonder why someone else guts your shit - they understand the basics which you failed to learn.

The Turing Machine architecture doesn't help...

[Anonymous Coward]

Most processors are designed around the memory-tape stack+heap architecture that is fine in principle (it works and is efficient) but memory security has always been an afterthought. In early computer designs, you weren't concerned with intentionally malicious code - you were dealing with mistakes made by your own users. If the stack smashed into heap, or you pointed to the wrong address, or loaded too much data into an object - you would find out the hard way and avoid doing it again. The external threat does the opposite, and intentionally sends signals to trigger errors and poorly documented features while keeping the system operating. The hijacking of these types of platforms is possible because access to shared memory space has been granted to everyone and everything - and it shouldn't. We foolishly rely on our operating systems to enforce things that should really be established at a lower level. Ideally, all external interfaces to a computer should have dedicated and isolated memory spaces with no direct interaction from the CPU... perhaps something like.. http://www.poxix.com/eal

Poor education

[Goonie]

I teach IT at a top 100 global university. Until a couple of years ago, security was not covered at all in any of the compulsory units for any of the IT degrees. It's still not mandatory in every degree.

And I'm fairly confident that this is typical across the tertiary sector.

Now, I'm not claiming for a moment that university is the only way to learn IT skills, or that learning ends the moment you get your degree (despite what many of our students seem to think sometimes). But a lot of our students come out of university and start writing production code with NFI about whether it's acceptably secure or not.

Re:Poor education

[djinn6]

Maybe software engineering will become a profession like most other engineering disciplines, with certifications to prove you understand security and other best practices. We'll probably need a huge disaster to happen before people to start noticing the problem and asking for it though.

Microsoft designs in security problems...

[greenwow]

then decides to try to play whack-a-mole. They don't design security in from the start like Linux and especially Red Hat.

agile scr(ot)um

[Reverend Green]

Maybe because also every company is doing Agile Scrotum, and they're Not Doing Agile Right(tm).

Re:agile scr(ot)um

[djinn6]

Ah, the "no true Agile" fallacy.

Re: agile scr(ot)um

[Anonymous Coward]

Whoosh!

True. And saves a LOT of time fixing bugs, scalabi

[raymorris]

That's true . In fact we can SAVE developers tons of time working with them to be more secure. Security isn't just confidentiality. It's making sure the software works correctly - even when someone is trying to make it break. Fixing bugs takes a lot of time. Following security best practices means the software won't mess up even when someone is trying to make it mess up. That implies it won't mess up when people are using it normally - far fewer bugs to investigate and fix.

It's also availability - avoiding DOS by making sure an application won't crash, even under heavy load. Ever had to re-architect something because it couldn't handle the load? Ever had to do that as an emergency because it can't handle the load *right now*? Had the whole network go down because one switch had a power supply failure? Consulting with your security person at the architecture design stage can help ensure the design is able to scale, and doesn't have single points of failure that can bring the whole thing down. Following good security practices means most emergencies are eliminated because it's designed to be robust enough to keep working correctly - even if someone is attacking it, and certainly when nobody is attacking it.
 

HA, Not only that.

[Anonymous Coward]

Wait until the Qbits get here. I think the concept of security is going to change by 10^1000. There can't be any such thing as a
"password" that is knowable by humans. Your winkie little deterministic, classical physical computers are in deep shit.

Move fast and break things

[Anonymous Coward]

For most software, there is no consequence for shipping an insecure shitstain.

Therefore vendors cut corners and take risks as they are highly unlikely to be held to account for the consequences for their actions.

90-95% of cyber attacks/intrusions can be shut down by:

- patching OS quickly
- patching Apps quickly
- not running as root
- only installing Apps from trusted sources
- not using Flash/Java/Office Macros
- Using multi-factor authentication whenever possible
- having a daily backup

(Ie pretty much every iOS user)

You can bag Apple as much as you like, but their process appears to work: after 10 years, with > 1 B devices, thereâ(TM)s been virtually no malware on the iOS platform. Nothing else mass market gets close.

writable = infectable

[Anonymous Coward]

(1)
You should run all your critical software from non-writable (ROM) memory.
Nonwritable = noninfectable.
In that respect we should go "back to the eighties". In those days they built computers that could not get infected. The computer industry has to give up the concept of a patchable OS.
(2)
I agree with DogDude. (Same story; have been shouting this for years.)
If they can't give me a working OS (+browser+file editors+mailer etc) on a ROM I want my money back.

-- Zomboid

because... it's complicated

[Tom]

The primary reason is that software quality is down the drain. We actually know how to write software two orders of magnitude better than what we have now (the metric being bug count). There'sa single-digit number of companies in the world doing it. They are successful, and the business case is ok (less maintenance cost and issue-related costs down the road), but only if you look at it long-term and with a dominance of short-term thinking, well, we have the mess we have today. Startup culture especially is the enemy of software quality, because within 2 years you must be big or bust. That prevents investments in long-term quality and time-to-market is also critical, pressing on the timeframe.

The second reason is that we have abandoned academic (i.e. provable) software design. Again, there are a few exceptions, P3KI for example has a formal proof (disclaimer: I know the guys behind it) as do a small number of other projects. But most "security practices" are basically made-up. Maybe they are good, maybe not, you don't know because they're based on intuition, not proof or facts. A guy named Bell a couple years ago rightfully lamented this fact, and he has very high credentials (google "Bell-LaPadula model").

The third reason is that bad guys are lazy, incompetent and/or busy. It is incredibly easy to break into most systems, but most of the bad guys these days are in it for the money. That means they look for ROI as well, which means they attack only the weakest targets. That is why most of the stuff we see on the malware side, or on the hacker side, is not exactly rocket science. In 15 years of career in the field, I found a true zero day on a compromised machine once. And that in turn means that from a protection perspective, you can be quite secure with a more or less minimal level of security. Because as soon as you are not the weakest target anymore, 99% of attacks will bypass you and hit someone else. There is no incentive to really improve security baselines, because it doesn't pay out.

It's a shame, really. We made jokes about the quality of windows in the 90s. Now the joke is on us.

Re:because... it's complicated

[djinn6]

The second reason is that we have abandoned academic (i.e. provable) software design. Again, there are a few exceptions, P3KI for example has a formal proof (disclaimer: I know the guys behind it) as do a small number of other projects. But most "security practices" are basically made-up. Maybe they are good, maybe not, you don't know because they're based on intuition, not proof or facts.

You actually can't prove something is secure. In fact, most crypto is provably insecure, because with enough resources, everything can be decoded, and you can't prove the attacker will never have that kind of resources.

Re:because... it's complicated

[Tom]

Yes, you can. Formal proofs are a real thing.

You cannot create a proof for everything, and for reasonably complicated algorithms, the proof may be too complex to create. That is true for most cryptography.

But there are quite a few things that we could create formal proofs for, if we wanted to. You don't have to believe me. You can go to the search engine of your choice and find a few actual formal proofs.

Insurance would be great. That's how we got fire s

[raymorris]

The fire code is written by the National Fire Protection Association, a group formed by insurance companies, in order to reduce their losses from fires. Underwriters Laboratories (UL Listed) who check products for fire and electrical safety - same thing. "Underwriters" means insurance companies. Insurance companies are professionals at analyzing and reducing risk and they do a VERY good job of it. They use very advanced methods to determine risk. I'd LOVE to see insurance companies get involved in IT security, the same way they are involved in fire safety. Ever noticed car commercials advertising their high IIHS safety rating? IIHS is Insurance Institute for Highway Safety, insurance companies testing cars to make them safer.

> Insurance can pay out on the promises, and the insurers themselves are borrowing against still future promises to pay, which when they come due can be rolled over or hedged and thus the cycle continues ...

That's not how insurance works. The insurance company uses mathematical models to determine that of they insure 10,000 customers with a given risk profile, about 1% of those customers will have a claim. The average claim will be about $3,000, suppose. That's $300,000 the insurance company will have to pay out this year. Divided by the 10,000 customers, that's $30 per customer in claims. Each customer also costs $3 for mailing invoices and such, so the average cost per customer this year is $33. Therefore the premium they charge is $43. $10 gross profit per customer.

Insurance companies aren't betting hoping they don't have claims. They have a million customers, of course they'll have claims. With a million customers, the law of averages kicks in and they can predict rather accurately how much the total claims will be this year. So then they set the premiums (their prices) for the year a bit higher than their costs.

The one big thing that can screw that up is a major flood. A major flood could have a million people making claims all at once. That's why insurance companies don't sell flood insurance. Only the government sells flood insurance. (In the US at least).

It's normal

[nospam007]

If you hire a music major as CIO, like Equifax, everything is possible.

Re:It's normal

[hexed_2050]

That, and kids disabling SELinux because they don't understand it.

We are the problem

[bothorsen]

What do we do when we need a new CPU? We go to one of the hardware sites and look at the performance tests. And then we compare the performance with the price, and choose the one that fits us.

Where is the security focus on this? Exactly where we asked for - nowhere.

But but but, we say, this should of course just be there. Well, no. It doesn't work that way. If you choose based on security, then much more effort will be spent on security. If you don't they won't. It will never be forgotten, of course. And obviously all manufacturers try to give us secure products. But when it's not the main selling point, then there is a limit to how much we will get.

And it's exactly the same for software.

It's the old saying: Cheap, fast or effective - choose two.

Java got critical mass in the browser

[raymorris]

For many years, Java was basically the only way to write software that ran in the browser. It was with either Java or try to get web site visitors to install your custom plugin for your site. That's how Java got critical mass - developers who knew the language, books, libraries in Java, etc.

At that time, Java was only used in the browser because back then it was dog slow, inconsistent, and just generally not a good programming language - but it was the language browsers supported, so it was the language you had to use.

Java has gotten a lot better as a language since then.

Re:Java got critical mass in the browser

[jellomizer]

CGI apps can be coded in nearly any language. To prove the point I once wrote a web App in FORTRAN 77.
While JSP made it easier it wasn’t the only game in town. And the Applet never caught on for too long.

Re:Java got critical mass in the browser

[Anonymous Coward]

I'm not sure who wins this one, but at a previous job I had to set up a web server to run CGI written in COBOL.

Re:Java got critical mass in the browser

[Hognoxious]

Done it in bash. Just to test, scout's honour!

Re:Java got critical mass in the browser

[ctilsie242]

I've set up a website using Ada CGI apps before. Wasn't ideal, but it worked and did the job.

To kill a cockroach with a nuke?

[Anonymous Coward]

I've been doing sec, both telecom and and comp for a long time. To be quite honest, I've left the business...for good. We can have all the technical discussions we want until we are blue in the face. The bottom line is, for me at any rate, I couldn't deal with being redundant and experiencing the same *blonde coma look* from management not taking these issues seriously and considering security breaches a 'cost of doing business'. There's no punishment, so companies don't and won't, change their business practices. I became fed up with the inter-department fiefdom wars and sysadmin/netadmin 'not in my job description' attitude. Those of us that have been doing sec long enough have experienced this. If you do security and you say you've not been a victim of it, then you're a liar and you don't do sec. Just like if you've been doing security long enough and you've not made enemies or mutual, personal, grudges...then you're a liar and don't do security.

Recently I was asked what it would take for me to put together a team and get back into the business and I said, "nothing would." When asked why not, I replied...
"People on the net, and in the security community in particular, are very territorial. These days most of the people that do security that are good and really good, do so behind the scenes. The one's with the faces that everyone sees, are either known and highly respected through their research or have made a name for themselves based on past exploits. As a whole, these days, security people are loyal to themselves...their fiefdom...gold...and lulz (which I had to explain). I further said, "It's going to take a Pearl Harbor level event to bring the entire security and dev community together with a singleness of purpose for a long, focused, duration...because at this moment...the war is already lost and trying to convince yourself otherwise is a waste of fscking time."
A little background on me:
1. In '80 I was already writing code in COBOL, Fortran, and Assembly, while my peers of the same age were learning goto loops in BASIC.
2. NORGCA11, was my personal play ground from '82-'88 and I was not a PacBell employee ;-)
3. Jello shots all night in the PBI NOC
4. SN is and always will be the GOD of IDS
5. VMS anyone?

The need for Data Centric security as a model

[Anonymous Coward]

Historically, data security has been mostly based on the concept of walls. Build a wall around the data center, build a network wall with routers and firewalls, build an access control "wall" requiring authentication... etc etc.

Today, though, data doesn't stay in a data center, on a particular platform... data goes everywhere. SaaS, PaaS, Cloud, Big Data/Data lakes, mobile devices, and whatever comes out next. We can no longer rely on the typical methods that made us "safe". An organization may have spent the past 20 years, developing "layers of security" to protect their systems... and now data has simply jumped the gap, and gone wandering about in the 21st century.

This is why the data-centric security model is beginning to really gain traction. With data-centric security, you apply the security to the data directly (encryption/tokenization), protecting key sensitive fields in a data set. A single centralized policy should be defined determining which business use cases need the real data, and which specific data they need. Then that policy is enforced everywhere, from the SQL server in the data center, to the mainframe to the cloud to your favorite SaaS provider or S3. Access to the key material is handled separately from the system, so that there is full seperation of duties between managing a server/database/Cloud service etc and managing access to the data centric policy. This means that "oops, my S3 wasn't properly secured", results only in leaking tokenized or encrypted data... with no access to the cryptographic key material. "Oops, someone hacked my DB Admin account", results in the attacker seeing only encrypted/tokenized data.

This allows an organization to begin to distort their security resources and layers to focus on the smaller group of business use cases where the real data must be available. Additional security controls, training, auditing can be focused on the users, systems and processes that are capable of accessing the data.

Human error, software and hardware bugs will always exist, protecting the data itself is the best way forward.

Software freedom is better than 'hoping'

[jbn-o]

The good news is much like Charlie Rose gets embarrassed off the national stage, hopefully companies that don't take security seriously will be forced into bankruptcy.

Hoping for some unaccountable process to help users is no substitute for software freedom. Hoping is apparently flatly incapable of addressing purposeful choices to not fix remotely-exploitable problems (whether bugs put there by accident or weakening something on purpose like Microsoft did with the Skype protocol to make it easier to spy on Skype users).

Proprietary software is often malware and there are plenty of instances where the proprietor goes unpunished despite years of anti-user aggression (Apple's iTunes being vulnerable for years allowed spying, Microsoft Windows ignored user privacy settings, Google admitted it tracked user location data even when the tracking setting was turned off). Each of these problems and many more could have been fixed for virtually everyone by sufficiently skilled and motivated users if the software involved were free software, but users were not allowed to inspect the software, improve the software, or distribute improved variants to others.

There are no guarantees of program security so a useful perspective focuses on how users can improve the chances they'll get software that does what they want. Hoping for something better is foolish, passive, and completely unnecessary.

Hold on there for a moment

[Anonymous Coward]

Yes, the big issue here is that it's common knowledge consumers by and large refuse to be bothered to get educated

This is an enormously pernicious argument: The whole sales shtick hinges on "intuitive!" and "no training needed!"

Considering that consumers have been bombarded by that shtick for a goodly while, you really can't with any good conscience continue to blame consumers for doing exactly what they've been told to do: To shut up and consume. If you ever wondered why you should be careful what to ask for, here's an example: The industry asked for consumers, and got them. Turns out they're uneducatable, but that's how you wanted them!

So no, this is not the big issue. But it does show something else: A tendency to point fingers at things that aren't quite the real culprit. In other words, muddled thinking.

At this point it's instructive to look at an argument put forward by the late great computer scientist E.W. Dijkstra, who said that talking about "bugs" externalises the problem. Call them "defects" and it's no longer some external force of nature that crept into your code, allowing you to deny that the culprit is in fact you the programmer.

We actually also do that when we talk about "hacking" in the "modern" sense of "probable badness someone might possibly do with a computer somewhere in the vicinity". For if you go look at how the word is actually used, it really is used for just about any random thing that might be shown in poor-to-bad light. To the point of no longer carrying any useful meaning at all, except that vague sense of dread, that's actually more effective on consumers than on techies.

Yes, this also happens every time slashdot posts another story about the external cyber bogeyman, "hackers", who do unknown and unknowable things to your computer in the form of "hacks", thereby asserting the dangers of "hacking", whatever that may be. Slashdot with its current crop of editors certainly isn't the only culprit, the industry does it too, just about every journalist, even the government is guilty of this: The law against "computer hacking" outlaws it, but doesn't define what it is. That's bad law if there ever was one.

The point is, by externalising the threat, why, you can't own the failure and thus you can't be held responsible for the consequences. This is how the computer security industry marketeering is structured: The cyber bogeyman cometh, in fact is already lurking under your bed, so give us monies for a protective blanket.

Let this sink in: The computer security cottage industry does not exist to solve the problem.

They are consultants, in the demotivator poster sense. That is why they come up with the smallest tidbits of "security bug", give it a pre-announcement, an announcement, a press release, a fancy name, a website, and build a media circus around it. It's all about the show, not about the solution. They don't do big ticket things, they don't do real solutions. They do small stuff and selling subscriptions to keep the monies flowing. That has nothing to do with fixing things, but everything with making a good show of valiantly failing so there's always another day to try again.

They're selling security blankets out of new cloth for emperors. These are the security specialists. And you expect the non-specialist vendors to do better? They'll just give some monies to the specialists and claim they've done their "due dilligence" and that's the end of their culpability. (What other industry is big on this, and why is this so? Yes, the reasons are related. But I digress.)

Let me repeat: The computer security cottage industry does not exist to solve the problem.

and the bulk of the major software development companies out there aren't don't have leadership ethical enough to be able to resist taking maximum possible advantage of their naivety.

To the point that they promote the naivety in their marketing. Successfully, too.

Of course ther

Are you kidding?

[CustomSolvers2]

And why are so many faulty pieces of software, websites even developed/used by people/companies with much more than enough resources? Incompetent, ignorant, careless, etc. attitudes systematically promoted at different levels by a system infected by arbitrariness since quite a few years ago when the big amounts of money came in and, with it, all the people only seeing software development as means (which they don't know/like) to an end (= money); a situation which, ironically, might have been tremendously beneficial if everyone had focused on what they are good at.

You can take as a reference my personal recent experiences. I am a senior programmer with a very heterogeneous background currently exclusively interested in working under high-quality/technically-demanding conditions. I am more than willing to prove my knowledge, skills, attitude at work, even by spending a relevant amount of time, but I am systematically not allowed to do so!! All what I find are random tests mostly focused on ridiculously small amounts of time (this is exactly how you can assess what a person knows! By setting up completely unrealistic conditions and forcing that person to get trained in that specific format, cheat it or prove irrelevant-for-the-job skills), abstract questions expecting very specific absolute-truth like answers (!!), looking at your public contributions in an extremely simplistic way (analysis performed mostly via counting stars, likes and emojis) or any other ridiculous resource meant to provide the fake impression that a person without knowledge can seriously assess what an expert knows. And all that without forgetting about random assumptions, prejudices and any other arbitrary output basically defining a system where the gatekeepers only let in those saying exactly what they want to hear: mantras of either very low applicability or requiring a proper analysis which never happens. Basically, unkowledgeable people deciding who are (not) knowledgeable?!

I have many other experiences on different fronts but all of them depict the same ridiculous reality: a so relevant field requiring a relevant amount of knowledge and a very specific attitude which is being managed at almost every level by people with virtually no knowledge and not even liking anything of that (thinking that the technical skills are secondary?!). Having so many problems you ask? I wonder why we are not seeing much more than that. In fact, I am pretty sure that there are lots of problems which either don't get any publicity or haven't been discovered yet. Lots of problems is the normal outcome of a highly specialised critical subfield cluelessly managed by unknowledgeable people. I am not saying that the software development industry has no place for non-technical skills, but all these people should synchronise their activity with the reality and never forget that the ultimate goal of their activity is to make sure that the technical aspects (about which they know pretty much nothing and might even not like) are being adequately managed.

My guess

[Anonymous Coward]

My guess: Agile.

Especially when used as a silver bullet (ok, mostly due to cost saving, so "highly polished lead bullet" is probably a better term).

Ok, obviously not all problems stem from this. But one has to wonder how many flaws are introduced by having a couple of chat sessions with some customer and cobbling something together until he is happy (by how the screen looks), i.s.o. a proper design that keeps the need for security in mind.

Because software developers re-invent the wheel...

[OneSmartFellow]

...over, and over again.

Good software developers re-use mature code.   Naive software developers don't.

It takes years and years of experience (for some reason) to understand how important "The Unix Philosophy" is.  Startups like Uber don't want to pay for that expertise, they just want to produce a product as quickly and cheaply as possible so that they can start raking in cash.  Startups are not focused on the long term at all.  If they were, this kind of shit wouldn't happen. 

Lack of education

[Anonymous Coward]

Most of my software developer colleagues got their education between 2005 and 2010. Yet when they learned about databases and SQL they did not learn anything about SQL injection. Neither did I, but my education was in the late 1990'es. I did, however, already know about injection exploits because I read about them in a book around 1993. I don't know how old the book was, but other parts were outdated when I read it.

That SQL injection and preventing it (probably the easiest exploit to prevent) is not a part of learning about databases and SQL 20 years later, is a sign that nobody cares. Every new generation of developers need to learn by making the exact same mistakes as the older generations.

*Online* incidents, on *servers*

[DrYak]

If you take a minute to look at the bulk of major incidents in the last year, it's mostly poorly configured Mongodb and S3 buckets.

Which, among other, is also due to the fact that :

- most of the major incident happen over the internet, and target huge online services where server hold gazillions of juicy information.

- Mongodb is an exemple of technology that is widely deployed online (so chances are it run on the targetted server, unlike say, an obscure piece of home grown PHP code on your own homepage), and that is relatively new, immature and thus still have plenty of exploitable bugs to get discovered (in addition to the fact that it is still in "let's add more feature" phase of development, instead of "maybe we should start paying a bit of attention toward security") and thus is a likely target
(As opposed to the linux kernel, which is very likely to be also running on the server, but has a little bit more maturity, and a lot more scrutinity to it).

- thus mongodb is likely to show up a lot in major incidents.

No SQL Server, MS Exchange or IIS in the list.

Sorry, waht are thes ?I have been hear about them yet ?~

Some new modules for Node.js ?~ Could you point me to their Github ?~

There's the occasional ransomware but given the market share of Microsoft products, it's not bad at all.

By "markter share" you mean "got completely obliterated out of the cloud/bigdata/server market" ?
Outside of the desktoip, and a few corporate on-site servers, Microsoft has become completely irrelevant.

Most specifically, it has nothing to *directly* do with the kind of big data caches that are attacked during "major incident", except maybe running one of the cloud service - Azure - that they might run on.
Thus of course, you'll rarely find them mentioned on the big data leaks.

Microsoft is still dominant on the (office) desk and office server.
- you'll find it targetted a lot by ransomware, etc. but that not a big major incident, just a huge constant flow of lots of small/mid incidents.
- it might play a role in stealing critical document from 1 specific user (e.g.: credentials or documents necessary to forge a successful social engineering attack), which then eventually could lead to a massive data breach.

Re:*Online* incidents, on *servers*

[Anonymous Coward]

Some new modules for Node.js ?~ Could you point me to their Github ?~

...

Outside of the desktoip, and a few corporate on-site servers, Microsoft has become completely irrelevant.

You might be retarded

Re:*Online* incidents, on *servers*

[ctilsie242]

The ironic thing... PostgreSQL is a better MongoDB than MongoDB.

Re:*Online* incidents, on *servers*

[the_B0fh]

What do you mean? I'm curious.

Re:*Online* incidents, on *servers*

[lucm]

No it's not. They serve different purposes and are both excellent products.

For instance, MongoDB is awesome in the way it caches data and how the powerful engine allows for complex queries. It's also a lot easier to scale out than Postgres, allowing a mix of nodes to handle various workloads, such as having a few in-memory ones for the bulk of read requests.

Meanwhile Postgres is a terrific RDBMS. Just compare the supported precision in numerical datatypes between Postgres and Oracle. Postgres: "up to 131072 digits before the decimal point; up to 16383 digits after the decimal point". Oracle: "up to 38 digits of precision".

Truth: Insecure at the foundation

[salesgeek]

The elephant in the room is that we are building on almost 50 years worth of insecure software that runs on insecure hardware on even less secure operating systems connected to an even less secure network... Honestly, it is amazing that all of it works, let alone be as secure as it is. Safe by design languages are going to help a lot, but it will take 20-30 years for enough of the stack to be rewritten.

Bad programming

[xenobyte]

One of the first things I learned in Computer Science 101 was to test properly. If you do a proper internal and external testing you can actually prove that your code will do exactly what it should under any circumstances. There can no be any overflows or unexpected behavior because the tests will already have tested that and revealed the problem.

The problem is - even a very simple program requires hundreds of tests. A slightly more complex program quickly ends up with many thousands. I wrote a simple chess program (simulates just the board and validates moves, not any AI to make moves) and the number of tests required to test it was in the neighborhood of 300.000 tests. Doing such testing on an OS or major application requires billions of tests and that is simply not feasible. Then you cut corners and approximate, testing only a tiny subset and catch maybe 80-90% of the issues. But the devil is in the details and that's where the hackers find their gold.

Re:Bad programming

[DaMattster]

One of the first things I learned in Computer Science 101 was to test properly. If you do a proper internal and external testing you can actually prove that your code will do exactly what it should under any circumstances. There can no be any overflows or unexpected behavior because the tests will already have tested that and revealed the problem.

The problem is - even a very simple program requires hundreds of tests. A slightly more complex program quickly ends up with many thousands. I wrote a simple chess program (simulates just the board and validates moves, not any AI to make moves) and the number of tests required to test it was in the neighborhood of 300.000 tests. Doing such testing on an OS or major application requires billions of tests and that is simply not feasible. Then you cut corners and approximate, testing only a tiny subset and catch maybe 80-90% of the issues. But the devil is in the details and that's where the hackers find their gold.

There is no monetary incentive in good programming. If the software is well-written and stable then companies won't have to purchase expensive support contracts in addition to the purchase and licensing prices of said software.

The answer

[DaMattster]

The MBAs have pushed software products to market without adequately testing and troubleshooting. The bean counters want to reduce the expense of research and development when it comes to software and hardware so the result is a crappier end product with security holes. The whole thing began when these business types discovered a vertical market based on support of the shitty software. They would just force a product still in beta onto the public, have the public buy the product and do the testing, and have the public pay for "support" when the inevitable problems arose. From a business standpoint, it's genius. From a moral, ethical, and quality standpoint it rings of a scoundrel.

The procedural paradigm is inherently vulnerable

[cjonslashdot]

Several reasons. One is that the imperative languages we use are inherently vulnerable to TOCTOU (race condition) errors. We should be using design level languages. However, while design level languages and architecture level languages have cropped up in academia from time to time, programmers - who are largely self taught - have not learned of these and don't want to know about them anyway, because it is more fun to just "code".

Another problem is that all of the incentive today is around producing more features fast. This is because software producers are not liable for damage caused by vulnerabilities. Until that changes, nothing will change. Most programmers know very little about application level security, because their employer is not telling them that is the priority. There is no incentive - if there were, programmers would respond.

It starts with bad programming languages

[thisisauniqueid]

It all starts with bad programming languages that give you enough rope to hang yourself with, or a gun to shoot yourself and others in the foot with. I'm not even a Rust fanboy, but consider Rust for future projects, as it is probably the safest language today (at least from a security point of view). And even better languages are coming.

As a government tester

[Anonymous Coward]

At one time I worked for the NUSL in New London testing classified software for exactly this issue.
It easily triples the cost of development to offer an assurance of correctness without any feature checkmark to show for it.

When you are expected to offer more new features than the competitor each product cycle, without pressure from some regulator, testing is virtually entirely a time and money sink.

Because we're dumb...

[Timothy2.0]

Simply, the *potential* we have at our fingertips, with respect to computers, etc, is VAST. Our knowledge of how to use those systems, however, barely scratches the surface of the surface.

When someone with greater knowledge of those systems comes along and makes the layperson look like a digital chump, bad things tend to happen: either the more knowledgeable seeks to "break" the system, using it for something the laypeople don't tend to think the system can do, or the laypeople get bent out of shape with their ignorance displayed for all to see. In the latter case, people get defensive, try to implement rules and regulations to return the use of those systems back to their own comfort level...

Fundamentally Insecure

[Anonymous Coward]

The computer architecture is by design insecure and we are only applying bandaids at best. Without a fundamental redesign of the computer hardware architecture, there is no way to totally secure a computer...unless you unplug it and put it back in its box.

Greed and Laziness

[forkfail]

I would propose that while there are certainly a number of bona fide bugs out there that are simply legitimate oversights that just don't get caught, greed and laziness make up for the vast majority.

Greed and laziness are what drives the business side to make schedule demands that cause corners to be cut. And since security isn't a visible feature until it breaks, guess what gets cut first?

And then there is maintenance of security - the patches, security bug fixes, and so forth. That is a zero sum gain task for any admin or developer. It adds no visible value. And eventually the powers that be start asking questions like, "Why do we pay all these guys who neither write shiny new code nor install my printer nor do anything else that I can see?" But when these guys fail, guess who gets the axe?

Anything is hackable

[Anonymous Coward]

The reality is that as devices do more so does the potential for it to have flaws. The eternal cat and mouse will always be a part of technology no matter how devoted people are to creating secure software and devices. The other fact is we are dealing with multiple devices with many different OS's and software/apps. So while it may seem we have more exploits we really just have more stuff affected.

buffers for example

[jbmartin6]

I sometimes ask the same sort of question. A lot of classes of vulnerabilities seem completely unnecessary. For instance, buffer overflows. Why is it possible to overflow a buffer? I think the kernel should just refuse to do it. It is easier to fix something once than ten thousand times, and asking companies and coders to "care about security" is trying to fix it in ten thousand different places. We don't see buffer overflows much anymore since the behavior of the systems have changed after twenty or thirty years of exploits. Now I'm sure this is at least in part due to my own ignorance of how the kernel works. I also suspect that the countermeasures are expensive and thus were not included in the interest of performance. End rambling old man tirade.

Re:buffers for example

[CustomSolvers2]

For instance, buffer overflows. Why is it possible to overflow a buffer?

This happens when the programmer has to expressly deal with all the memory management aspects (i.e., allocating enough memory before using a variable and releasing it afterwards) in languages like C. There is no real difference between this or other kind of bugs: outputs of a wrongly-built piece of software. The reason why it is much more difficult to see these errors nowadays is that more modern programming language take care of all the memory management automatically. Including this automatic memory management part consumes resources and this is one of the reasons why these language are heavier/slower than C. These more modern languages can still be misused and create buggy software, but they are usually much more programmer-friendly (what is a quite personal assessment anyway).

Re:Insurance would be great. That's how we got fir

[Anonymous Coward]

> The one big thing that can screw that up is a major flood. A major flood could have a million people making claims all at once. That's why insurance companies don't sell flood insurance.

Maybe true for floods (and for high-risk areas in e.g. Germany you won't be able to get insurance either), but for other cases this is solved by insurance companies that do nothing but insuring insurance companies against the most exceptional claims. They have a HUGE amount of capital.
The reason for not offering insurance isn't necessarily that the risk is not manageable, it is rather that the cost of doing so would result in a product nobody would buy anyway - especially as at this price level you would have a self-selection effect, driving the prices and risk up even more. Would you buy a flood insurance that costs e.g. 30% of your house's value per year?

Built for Speed, Not Security

[drinkypoo]

When Windows NT4 came out, security and even reliability took a gigantic dive as compared to 3.51. Why? Because Microsoft merged the Kernel and GDI memory spaces in an effort to improve graphics performance. It worked, but it horribly compromised security, as now a hole in the graphics driver meant a hole in the kernel.

This attitude is pervasive throughout computing. We are willing to sacrifice 90% of our security for a 10% improvement in performance. I, for one, would prefer to see a credible microkernel-based OS built for security first. If that means I'm wasting 10% (or even more) of my cycles, so be it. At least I'll be able to trust my computer.

All of this is why,

[Grand Facade]

Driverless vehicles are such a bad idea.

99/1 realistically

[ctilsie242]

I would assert that it is a 99/1 ratio. Security is a solvable problem, and we have had rigorous, solid, time-tested methods of security since the 1960s and 1970s, be it physical security, network security, or security of a computer.

I did an "Ask Slashdot" about a similar topic a few weeks ago, but it was more inclined to why companies have no interest in security, because (to them) security has no returns.

The problem is that we already know how to do segmented operating systems, windowing systems that have varying levels of security, application security, solid encryption with good key management, secure tunnels. All mainstream x86-64 and ARM CPUs come with AES in hardware and a hardware RNG (even if you have to run it through Yarrow like FreeBSD does, just in case.) The issue is that developers cut corners. Why use a 4096 bit key, where big-O for this is O(n^3) when you can use 64, 64 bit keys for a fraction of the CPU? Why use all 14 rounds for AES-256 when you can use just one? Why use a salting/hashing mechanism when you can just store the password as plaintext? Who will notice? Who will care?

Then we get to more fundamental things. Why should developers care about security at all? If they don't make their deliverables for sake of security, they get admonished for it in public at the daily stand-ups, if not eventually fired. If their code causes people to sue the company, then the lawyers are the ones handling that... not the devs. Even if there are consequences, they are less than not making the sprints.

Then, we get to the bottom line: There is profit to be had by insecurity. If a CEO finds out their company got hacked, they can short their stock, wait a few months, announce it, and profit tidily. Insider trading laws are easily skirted around, especially if there is a few months delay between the transaction and the announcement.

To;dr, security is not a matter of "can't". It is a matter of "won't".

Complexity

[Anonymous Coward]

The level of complexity in any non-trivial software system is so high it becomes impossible to test it all and guarantee its functionality. If hardware was able to reach the same level of complexity, nothing would work.

Re:Complexity

[the_B0fh]

There's a difference between unsafe cars, and well designed cars, but still having accidents.

Driving one of the cars in Unsafe At Any Speed versus driving a modern car - both will have accidents. One will kill you. And cause more more accidents. The other will reduce the number and severity of accidents.

You can have things break, but you can cause it to fail in a way that doesn't cause a security issue (well, as much as you can).

Why bother?

[Anonymous Coward]

Sure, it is possible to make code very hard to hack, but:

a) it's much more expensive

b) you can't use the available open-source your competitors use so it means your product takes much longer to get to market, and

c) nobody really cares about it.

The lock on your house can be picked by a kid with two paperclips and training from Youtube. Are you going to go get a much more expensive lock that can only be picked by a professional? Wouldn't a burglar just kick the door in instead? You should keep your money in a regulated bank with government insurance rather than in gold bars protected by your front door lock.

The real question is "Why are so many companies storing gold bars in their hallways?" or really "Why are so many companies storing so much data that can be stolen and used to harm their customers?". If you securely delete data from your systems then you are 100% sure that hackers who break in next year can't get it. Companies are run by short-sighted idiots who know nothing of technology risks and buy into marketing that tells them customer data is "super useful" in spite of ample evidence to the contrary.

Because companies are cheap

[Anonymous Coward]

It is far cheaper to hire a contract place like Tata or Infosys to use their Java or C++ programmers in their offshore shop than it is to get a dev team which knows Ada well, and is able to program securely.

Full stack security flaw

[Anonymous Coward]

For one, there's a full stack of APIs that are insecure. Something as simple as sprintf() and/or sscanf() in the C programming library tend not to use bounds checking by default, the user has to explicitly remember to use them. Then there's things like SQL injections, etc. The various tutorials teaching people how to code guide them towards the insecure practices that cause these problems as well.

And, you can't fix these problems until you do a full-scale rewrite of the insecure APIs, breaking 30+ years of software compatability.

Complexity

[ruggard]

I'm a software development professional and I only know well a few corners of the software and operating systems universe.

I've met people much smarter than myself, who knew several times what I know about every technology under the sun, yet nobody has in their heads the entire technology stack - from silicon to circuits to logic to BIOS to CPU instructions to operating system to multiple levels of abstraction on top.

I've been thinking about this a lot lately when I get frustrated with my own devices and my own software: everything you build, no matter how carefully, is interfaced with several things that you know only the most tenuous bits about.

Not even the most well-informed security experts can keep up with all the services and modifications that are live on a typical laptop or regular desktop. It's too much - nobody has the time, let alone the intelligence, to see it all and fit it all together.

It's sheer quantity - there are so many ways software can go wrong. There are so many ways your computer can be accessed from the outside world. There are so many ways you can mistakenly click on something that compromises your machine.

And everything else people say is true - many devs are lazy or in a hurry, many are incompetent, and many software vendors have no idea what they're unleashing on the world - they're just desperate to release the features that matter to them.

I honestly believe until we go back to massively simpler architectures in both CPU design and OS design, this will be a simple, basic, ominpresent fact of life.

Coders and Management

[Anonymous Coward]

The problem is lazy coders not doing input checking and cheap management not understanding that input checking is important. If all coders did input checking all the time in their code, 90% of vulnerabilities would magically disappear.

Read The Software Conspiracy

[the_B0fh]

Mark Minasi wrote a book called The Software Conspiracy. People just don't give a shit about secure software.

And most people just don't know how to write secure shit, and don't care about learning.

How many developers know about OWASP or have taken and finished all the training materials OWASP offers? Why haven't they?

Not in scope: Principle of least privilege

[redmasq]

I cannot speak to your "Data Diodes," which sounds like a marketing term for a firewall (several types of common network interfaces have, for performance reasons, separate send and receive lines) or your virtual machine idea which resembles a micro-kernel architechure with container based applications.

Concerning principal of least privilege itself, it can be applied to end-users or "system/application resources/providers," e.g., services (which I shall use a blanket term). From a programming point of view, this involves having a sufficient granularity of privileges which then can be assigned to roles, groups, users, etc. The one configuring and managing the security of the system only gives access to users and services that require it: an end-user might need to the privilege to change the current display settings or a service might need the privilege to access the filesystem while temporarily inheriting the privileges of the caller. Those would be given the privileges they require, and no other. As another consideration, from a programming view, let us say that the service needs the privilege to check the status and potentially start another service, but only while initializing. The original service would be given that privilege, but as soon as it is done initializing it, it would, in more colloquial terms, waive its right to further check on and start other services.

One of the first difficulties is cost versus benefit. If the business needs the application in one month (to use the extreme, yet common excuse of "otherwise we miss the market and goes closes doors"; although "we'll fix it later when we're caught up" is pretty common as well), if there are exactly two users of an application in the specifications with reasonably well defined roles. The might decide to forgo the cost of a granular system for a fixed role system. As long as there are only two types of users, this is not a problem. If users' responsibilities become more specialized or overlapped, then the business will need to make the decision on how much it is willing to spend in money, time, and development resources to change the system, assuming that it even has any to spend. This is even before considering the impact of changing the security model has on any user, application, service, or business process downstream. This also does not consider the human element of "I'm the boss/VP/CEO, I should be able to change the database or log into any system any time I want" or similar scenario.

Even with such things, principal of least privilege is not a silver bullet. A common task for a user is to open a file. Let's say, for example, that the file is clip art file and a "non-privileged user" cannot import it into their document and the program crashes. The user submits their ticket. We'll say that a IT helpdesk (arguably with sed -e 's/p/l/gi' been applied) member just has finished a dozen requests that requires escalated privileged roles carelessly remains logged into their separate superuser/admin account to work on that ticket. The ticket worker opens the word processor and tries to import the file. But then the clincher, the clipart file type is from an earlier era that where it was necessary to speed up the drawing by having it directly include kernel calls and the word processor just used the original library to display the file in the appropriate part of the document. The file displays normally, the worker emails the user stating they cannot reproduce the problem, and a newly spawned minimized shell task just downloaded and ran an installer for malware. Yes, the worker was careless and maybe the wordprocessor developer could have put some type of protection, but then why spend the cost of doing so if the library does the job and the problem was not detected since the developing company's developers and QA are not familiar with the fine details of the format or bugs in the library's implementation.

The real problem is C/C++

[Anonymous Coward]

All software can contain bugs, but most bugs would be harmless, if most software were NOT written using C/C++.

Thanks to C/C++, tiniest bug anywhere in any software, allows a hacker to take control of a computer system.

The same problem does NOT exist in the newer languages, but almost all software is still written using C/C++.

Re:The real problem is C/C++

[CustomSolvers2]

Thanks to C/C++, tiniest bug anywhere in any software, allows a hacker to take control of a computer system.

What are you talking about? A very important proportion of all the software in existence (including quite a few other programming languages) are written in one of these two languages. When talking about basic/core infrastructure they even don't have any relevant competition! And I am saying that despite not using any of them too much myself, unless under very specific conditions! The only reason why a given programming language might be (un)safe is a bug in its code, what is thousands of times easier to happen in newer programming languages which have been used much less.

Some months ago, I read here an extremely ignorant concern about a memory overflow being a way to manipulate how the given program might behave!? The only thing that you can get after a memory overflow is the certainty that that program will crash, perhaps right away or perhaps after some seconds. C (and to a lesser extent C++) are definitively much less programmer friendly than newer languages; but even this is a quite partial statement as far as some people might feel more comfortable working with them. Other than that and the evident performance differences on some fronts (C being really quick), there is absolutely no problem with these languages. The corresponding developer + surrounding "issues" (e.g., clueless manager setting unreasonable constraints) is the sole responsible for whatever problem, including having relied on certain programming language without the required knowledge/experience.

Re:The real problem is C/C++

[CustomSolvers2]

With "The only thing that you can get after a memory overflow is the certainty that that program will crash, perhaps right away or perhaps after some seconds." I meant that the corresponding error might appear right after executing the faulty part of the code which provokes the memory overflow or a bit later. After a memory overflow, the error-message/crash is immediate.

Re:The real problem is C/C++

[CustomSolvers2]

Apparently, there is some other people also thinking that that nonsense is logical. They have even written quite a lot about this in the corresponding Wikipedia page. The text there (lots of generic talking and not many practical examples because well there is none) seems quite descriptive of the worst case scenario of this "threat" and the kind of partiality and fanaticism that, unfortunately, it is too common within the software development industry, following whatever daily trend, over-concerned about what is irrelevant and ignoring what really matters. Anyway, I will write my impressions about these contents to properly illustrate my point.

Logically (and unlikely what some people suggested here in the aforementioned article some months ago), you cannot directly access/modify whatever information is in a pointer/memory location of a running program. Apparently, the way to "exploit" this "weakness" is to hope that a random value (within a huge potential range) might have any kind of effect on the given application. So, imagine that in a given method (out of the potential thousands, even millions of methods in a piece of software about which you know nothing), a variable (out of the potential thousands, millions, etc.) is expected to get the value "123456"; but the given code performs the required memory allocation wrongly and provokes a buffer overflow, what changes that value to whatever other one might be associated with said memory position. Under the most likely conditions (around 99.99999999999% of the cases, I guess), the resulting value would be crazily wrong and an error would be triggered. But, in some very specific case, it might happen that the resulting value might be good enough to not provoke a crash. So, in that virtually-impossible case, you would have accomplished the marvelous result of having modified the value of a variable, out of many, about which you know nothing to a different value about which you know nothing!

And this is your breach of security! This is what makes you think that it is a good reason for stopping using a given programming language!! Are you being serious?? Have people forgotten about self-respect, objectivity and professionalism or what on the hell is wrong here?? As commented in that other thread some months ago, I did find a way much more relevant problem with applications used by open .NET to compile their public code! It was possible to directly affect the pure source code of a running executable!! And my conclusion was that this couldn't be seen as a threat because of being extremely unlikely to be exploitable under virtually any real scenario! But this was (Microsoft changed it a short while later) orders of magnitude much more dangerous than the aforementioned nonsense! And they have a whole Wikipedia page and apparently some fans! All what I got with that analysis I made was the problem to be fixed (no idea if because of me; nobody told me anything), having to update the text to reflect that change in the conditions and not even a single comment!! I don't expect anything else, because I don't see the true relevance of all that, but why these people do all that! And then you get millions of records stolen on a regular basis because of not performing the most basic actions; but rather than focusing on performing said evident actions, you get completely paranoid and start seeing problems in the air!!! I am not trying to criticise certain people or sub-field or "experts", but an attitude, very relevant for this specific thread: how can you complain about software having lots of problems with this kind of things! What person really wanting to fix/improve/help could give even half a shit about what I am describing here? I don't even think that these people have developed even the simplest piece of software in C/C++; otherwise, I can honestly not imagine anyone feeling like spending their time on such a nonsense. This is another cancer of software development: generically talking, prohibiting, fearing, guessing, blaming, etc. most of the times with low-to-no relevant expertise! Pfff... Well, I guess that this has been an excellent epilogue to my previous post and my ideas on these fronts.

Glad you asked ...

[CaptainDork]

... because I know the answer.

I got my first computer in 1978 (TRS-80) and I've been doing digital shit ever since.

Appreciate that computers were standalone devices and like every other innovation (think cars and seat belts), people, including me, were very poor at predicting the future where every goddam computer in the world touch every other goddam computer in the world.

Going back to 1978, the OS had no need to self-protect because the only method of input was the keyboard and the only output was the monitor.

That "air gap" beginning set us up for failure in the future.

Once floppies hit and computers first got "social," the tech-savvy lulz peeps feasted on the vulnerable core of the OS.

Hobbyists launched the PC, and that culture exists today where the user is expected to be knowledgeable regarding consumer electronics.

From the business side, it's damned near impossible to retrofit OS for security and even harder to roll out a completely new, secure OS.

Security is expensive, even when it comes to keeping up with patches, and consumers want inexpensive stuff.

The next step is litigation against the vendors and gatekeepers of the data.

A number of cultural reasons

[ilsaloving]

There are a number of reason that all contribute to this sad state of affairs, and unfortunately it won't get any better until something drastic happens, on the calibre of software developers becoming regulated like other kinds of engineers.

Ageism - There is a major preference to hiring young people over old. Young people are cheaper and are willing to work more ridiculous hours. The problem there is you push out the people who have already made the mistakes and learned their lessons, causing the same mistakes to be made over and over again.

Education is frowned upon - There's a major shift towards people who are "Self-taught", etc. While having a degree isn't a guarantee that a person is any good, it's a hell of a lot more likely that they are. It's a Dunning-Kruger issue. I've run into a number of self-taught people who had absolutely no knowledge of all sorts of critical concepts that a competent developer should know. How to write de-coupled code. How floats work at the silicon level. The importance of Big O notation. How to write certain algorithms efficiently. And the resulting code quality is understandably shit. Just look at Facebook's mobile apps... last I checked they came to approx 750MB for a f__king messenger app and a newsfeed viewer.

Lowering the bar - Companies et al are constantly trying to lower the bar for new people to get into development. This feeds into the above, because it means it's easier for people who know little to slap something together. The problem is that this leads people to think that they actually know what they're doing when they don't, and the resulting mess is there for all to see. Wordpress is a great example. Not just the main package, but their "community" of breathtakingly shit-tastic plugins that is a ginormous graveyard of poorly written abandonware that do a great job of contributing to Wordpress's reputation for being a security nightmare.

Old is busted, new is hotness - For some inexplicable reason, everyone seems to be convinced that new is always better than old. Software is the only industry where people not only reinvent the wheel over and over again, they *revel* in it, and other developers eat it all up, even when that technology isn't time tested and has an excellent chance of getting trashed after barely a year or two. Javascript is a fantastic example of this.

Silver bullet paradigms - People flock to agile and continuous delivery as if they will somehow magically solve their development pipeline problems. But it does not and cannot replace spending a little bit of time planning out a vision of your product, etc.

Finally, companies are not held accountable for their products unless someone dies, and even then only maybe. Too many companies treat software developers like factory workers instead of professional engineers, which helps facilitate all of the above, and as long as they can get away with no accountability to their customers, they have no incentive to do things properly.

Tradeoffs

[bigchrissd]

Software:
o) Easy to use
o) Low development costs
o) High security

Pick any two...

Cost

[Anonymous Coward]

It is possible to produce incredibly high quality software. The design, implementation, testing can all be made extremely rigorous. You can test over every possible environmental condition, fault condition, do 100% unit testing and even testing that aims to evaluate 100% of every possible code path. And, for some applications such as aircraft avionics systems, that is exactly what manufacturers do. For a "simple" system that might mean a few million $ NRE; for a more complex one such as avionics you could be looking at $140M NRE just for the design, implementation and testing, plus big bucks for the high reliability hardware to run it on.

That's a huge investment. In the case of the avionics set, the NRE for a new military avionics system (before you've even bought the actual system for a single plane) costs more than an entire offshore patrol vessel for the Navy. The spend is done to prevent bad software killing people. Even in these systems, problems can happen.

And even that avionics set is a ridiculously simple piece of code compared with the amount of code there is in something like Windows, or Office, or Flash, or Android. It's simply mind boggling to imagine the amount of testing that would be required to get a fair percentage of code path execution coverage.

Your average software house simply can't afford to spend this. They aren't making products that could kill people, the customers want their software as cheap as possible (especially the stuff that goes in essentially disposable devices like an IoT lightbulb) and there just isn't the demand.

You mean of those REPORTED?

[Anonymous Coward]

You mean of those REPORTED?

Re:You mean of those REPORTED?

[lucm]

Do you have compelling evidence that security incidents are less reported when Windows is involved than when other technologies are involved? Because otherwise your point is meaningless, and in any event it doesn't warrant uppercases.

Because it's theoretically impossible.

[Anonymous Coward]

If you think that this is even possible, please learn about the halting problem.

No.

[Anonymous Coward]

The insurance industry is nothing more than a legalized mafia protection racket. Our healthcare system wouldn't be such a disaster if insurance wasn't involved. "Hey, you need our protection. [Little Billy holding baseball bat.] You wouldn't want little Billy here to have an 'accident' with your kneecaps. Pay up or something bad MIGHT happen to you."

Good software developers evaluate the source code to the software they use BEFORE using it. Unfortunately, good software developers are hard to come by.

Certification programs are much more effective at producing better results. For example, FIPS 140-2, while a tad obtuse and certification is expensive, only lets the best crypto software reach a certified status and policy dictates that the U.S. government can only use such software.

In the *browser*, vs in the server

[raymorris]

As you know, CGI programs run on the server. To do something in the *browser*, you had to use Java, or maybe Flash.

> And the Applet never caught on for too long.

Only for five years or so, but long enough to achieve critical mass since it was the only real option. ActiveX (formerly known as COM, formerly known as OLE) was very much not designed for the browser in the first place, and only worked (kinda) in IE, so it wasn't a real option for internet sites. It was used a bit for intranet.

Get some QA?

[duke_cheetah2003]

I am generally in the camp that says, this phenomenon is a result of programmers being educated, learning their craft before the internet was a big thing. Or they were educated/trained in a fashion that did not stress security focus on application development.

It's not like it's difficult to oops. It's super easy to think to yourself 'this will work fine,' and as soon as it's done, yer QA finds a million problems. Programmers while awesome, aren't very good at seeing their own mistakes. Just as a novelist needs another pair of eyes to proofread their work, programmers need QA and code audits to check their work.

This is where the REAL problem lies. QA is not really a thing anymore. Why pay a QA department when you have droves of sheeple on the internet that will happily test your product for you. Hell, often they'll PAY YOU to play with your garbage. So QA is pretty much nonexistent. I'd have to assume if you got no QA, you probably don't do regular auditing of your code either, since that costs money and time.

As a side effect of sheeple QA, some of your more serious 'flaws' might go unreported. Some sheeple are wolves and will hold their findings to themselves to exploit later when you least expect it. Or sell the exploits to others to make a buck.

So bottom line, if you want quality applications, you have to pay not just the programmers, but a QA and code auditing process too. And until companies bring back *REAL* QA, this will continue to be a serious problem that won't get better, instead it will just get worse.

As a side note I also want to point out, there's a lot of one-man development going on in the app-space, especially around smartphones. This is another major problem. As pointed out above, programmers aren't good at seeing their own mistakes. One-man development suffers even more from lack of proper QA and auditing.

Healthcare plans are not insurance

[raymorris]

Insurance is something that pays to cover risks, things that probably won't happen to you this year, and the expense would be more than the customer afford to cover out of their own pocket.

For example, home insurance will replace your house if it burns to the ground. You buy insurance because you couldn't afford to buy a new house out of your own pocket. You don't insure against needing to replace a toilet paper holder, or paint the walls, or weed the garden. These are ordinary, expected expenses that you just pay.

Car insurance will replace your car if it gets totaled. The average driver doesn't expect for their car to get totaled, and can't afford to pay for a new one with their own cash. Car insurance does NOT cover gas, oil, tires, spark plugs - ordinary, expected expenses.

Modern US health care plans get involved in every little $30-$60 doctor visit, and all the bureaucracy and red tape doubles the total cost of simple things like a checkup or vaccine. That's NOT insurance. Insurance is for unexpected events that you can't cover from your own bank account. An annual check-up, or flu vaccine, is both expected and affordable; it's not an insurable risk.

We used to be able to buy medical INSURANCE, coverage for *unexpected* events too costly to pay from your own checking account (ie major surgery or catastrophic illness). That was fairly affordable. For the ordinary, expected health care expenses you kept a few dollars in the bank, and later in a specific bank account called a Health Savings Account. Over the years various things have forced more and more crap to be covered by "health care plans" - you can't just buy medical INSURANCE anymore. That's added a lot of paperwork expense to what used to be a $25 visit for a sinus infection. Now you have $25 worth of doctor time and $30 spent on paperwork with the healthcare plan and government, so it costs $55.

Re:Healthcare plans are not insurance

[Kaenneth]

Except regular checkups, vaccinations, etc. PREVENT larger medical claims.

The real reason

[whyyisthissohard]

Intellectually inferior people pushed into positions by "equality"

Hardware and software are made by humans

[Anonymous Coward]

Anything we do is prone to mistakes. End of.

indians

[Anonymous Coward]

indians

Coders are Bad, m'kay

[Anonymous Coward]

Too many programmers are brought up on bad code, and copy and paste examples that are going on the internet. It's not ideal, and until we demand good code examples all around it's going to continue to happen.

Re:Insurance would be great. That's how we got fir

[Anonymous Coward]

you're an idiot.

they cheat.

don't be a fool, for all of your life.

No one with the capability or incentives to secure

[Anonymous Coward]

Intel and everyone else is compromised by cloak and dagger types who want Total Information Awareness and complete supremacy in the digital space. As long as they value access and control over robust secure infrastructure, everything will stay exploitable. Good luck building your own chip foundry to fix the problem.

How?

[ebvwfbw]

Ever work for a software company? Any company for that matter. There is something called a deadline. Pack as much as you can and get it all working before some date. As you get closer sometimes things are removed. Not just software, happens in the auto and other industries. Then it's released.

No magic yet. Things still have to go through old fashioned testing and code reviews.

80/20 rule

[NewYork]

aka https://en.wikipedia.org/wiki/...

Car maintenance helps prevent crashes

[raymorris]

Car maintenance such as replacing warn tires helps prevent crashes. You don't have the Walmart deal with your car insurance company every time you get tires or an oil change.

Maintenance of your home's appliances and electrical helps prevent fires. You don't call out your home insurance company to replace a worn $5 outlet - you go to Home Depot, spend $5, and get a new outlet. If you did ask Home Depot to fill out forms and bill your home insurance company, then wait to hopefully get paid, that$5 receptacle would cost $15. All that extra processing and time waiting to get paid costs money.

Have you ever noticed that your doctor's office probably has one doctor, one nurse, and two or three people handling paperwork for the healthcare plan billing? Want to make a guess why a visit to the doctor costs twice as much here as it costs in cash countries?

Re:They don't know how to cost-effectively. Locksm

[strikethree]

They aren't motivated enough to spend a ton of money on security.

Money can not buy security. Reducing the resources available will definitely detract from security. There is no simple answer relating to security that fits within our "modern" corporate environment.