CISA boss: Makers of insecure software must stop enabling today's cyber villains Software suppliers who ship buggy, insecure code need to stop enabling cyber criminals who exploit those vulnerabilities to rob victims, Jen Easterly, boss of the US government's Cybersecurity and Infrastructure Security Agency, has argued. "The truth is: Technology vendors are the characters who are building problems" into …
I once developed embedded software for a nice MCU with 4K Ram and 64K Flash. There was "plenty" of space left in the end. I created C++ Objects that consume 1 byte/octet.
So - you can indeed use a high level language and still create very small executables with a small Ram consumption.
The MCU was an AT90CAN64. Very powerful device, actually.
Surely it is the fault of poorly skilled developer, totally not the fault of management who hires them to maximise profits.
Training?
"No we can't do any training because the moment they complete it, they'll move jobs"
Why don't you pay them more, so they stay?
"Shareholders won't like that. Product is coming up nicely, we are doing fine with what we have."
How do you know that?
"We haven't got any major complaints or issues."
Yet?
"We will cross that bridge if we come to it."
Engineering Managers, Engineering VPs must be held legally responsible for sub-standard development techniques. Up to and including jail time for things like hard-coded credentials and obvious violations of regulations. Corporations must be made financially liable for violations of regulations.
Of course, now the question is "what are proper software/system regulations ?". A lot of damage can be done by stupid regulation, as always with laws+regulations. Doing nothing is not an option either, as U.S.G. has now found out.
Also, there must be a "ramp up" phase, from the current Wild West approach to Proper Regulation.
As a first step, force corporations to use PC Lint for the C code and fix or justify any PC Lint complaints. On the long run, make them prove memory safety of internet-facing code(first layer of SW) OR use Rust/Java/C#.
Yes, we need a good conversation about this. Civilized, enlightened, rational.
Quote: "...Makers of insecure software...."
Quote: "...Jen Easterly, boss of the US government's Cybersecurity and Infrastructure Security Agency...."
Facing both ways at once are you....Jen Easterly??
Some of us KNOW FOR A FACT that the US Government (aka Fort Meade) has encouraged Cisco Systems to ship "insecure software"...........
Why not take it on the chin?..........you Jen Easterly are part of the problem!!!!!
Why am I not surprised that the "US government" wants to walk both sides of the street at the same time?????
But, as mentioned by several above, writing bug-free, secure code is well nigh unattainable code, especially in a consumer economy where most often the cheapest product wins, not to mention quickest to market.
Heck, I literally woke up this morning realizing that I left off an entire necessary option in a project on which I'm working and now have to recode a module and redeploy before it borks someone's research results.
Just saying "nerd better" is not a magic panacea.
Perhaps we could establish some agency akin to the US National Highway Traffic Safety Administration (NHTSA) to do the equivalent of "crash testing" on products but I can hear the howls of pain from the Silly Valley bros over interference with innovation, the dead hand of government, yadda yadda, after just thinking such a thing. Probability zero.
Even if we did create something of that nature, how would we test all these widgets in all the permutations and combinations that exist, especially when they may interact with each other in strange and possibly undefined ways.
We do have UL, what used to be known as Underwriters Laboratories, but submission of a product to UL is voluntary (they're a private, profit-making organization) and they're really only concerned with things bursting into flames when they're plugged in. My understanding is that they've also got a huge backlog and it takes forever to get a product approved.
What's the answer?
Heck if I know.
One thing I'm pretty sure of is that naming the baddies by insulting names is probably not it. Most of those clowns would probably revel in being called "Scrawny Nuisance" or "Evil Ferret," I rather suspect.
Just look at some of the Xitter handles people take of their own volition.
Just look at "Elon Musk." What kind of name is that?
"but I can hear the howls of pain from the Silly Valley bros "
Given the way that the USA govt is disappearing up its own fundamental oriface, they may have good reasons for doing so
That said, there are OTHER national/international governments which could take up the baton
Well, the EU is a bunch of weakling-pacifists who will run to U.S.G. whenever a REAL threat(such as Vladimir or the Neo-Caliph) crops up. They can regulate to death(e.g. the USB connector regulation), but they are almost unable to develop an industry of our own.
India - highly corrupt and still kinda third world.
China - all depending on a single man ?
Brasil - bunch of lefties with bad friends.
So in the end U.S.G. must take the lead in this subject.
I did not attend the conference in question, so I don't know the entirety of what Ms. Easterly said. But the phrase "flawless code" does not appear in any of the article's quotes of her.
Drop the straw man of "flawless, perfectly secure code" and start with "more reliable, more secure code." Close the holes, fix the bugs, one by one. It takes years, and it's generally thankless. Welcome to your tech job future.
This needs to extend to installation practices and expectations, as well. I can't tell you the number of times I have been provided with installation instructions or even a helpful 'installation engineer' that expects a service account with admin privledges (I remember SolarWinds and CommVault specifically wanted accounts with Domain Admin provledges) or some other careless configuration that flies in the face of any security best practices. One may think the answer is to provide more limited configurations yourself, in order to keep configurations in line with security policy, etc. However, if you deviate from the given instruction set, the vendor will turn around and refuse to provide any of the support you paid for because you did not install it to their specifications.
I once worked with an engineer who was a true genius when it came to firewalls - setup, rules, configuration, changes, upgrades... however he never passed his CCSE (Check Point I am looking at you).
Why did he never pass it? It's simple, he knew each customers infrastructure inside out and Check Point's "perfect world scenario" exam questions would bring a company down if he implemented what they said was the correct answer to the questions in their exam.
I'm talking about huge, huge companies here, ones that your pensions rely on.
There's far too many companies relying on old creaking infrastructure that have easily exploitable bugs and defects. If you strap that on to the latest and greatest protocols customers demand then you have the perfect scenario for a world of pain and breaches. Acquisitions just add to the melée of creaky old tech mixed with fancy new tech and they don't work well together.
I'll bet most of these businesses have no idea about their hardware and software stack - it just works and makes them money... until it doesn't.
It's a sad state of affairs and will take decades to unravel, but until we do away with bolting new tech onto old cr*p we'll always have these issues.
My $0.02.
Corporations who provide essential services OR have more than 10% market share should be required by law to:
+ document all known weaknesses such as out-of-date/out-of-patch software and hardware, report to government
+ document all known weak scanners, parsers in use, report to government
+ lock down these insecure systems into enclaves with minimal external connections
+ similar sane measures to mitigate the effects of outdated and/or weak systems
Top notch corporations already do this at moderate cost and with great success. Now force the sloppier ones to do the same !
In most instances the fault lies with management - provide developers time to write the product properly, schedule in regular penetration testing, and checking of code as new exploits arrive.
Not always however. There was an unauthorised information disclosure at work, due to a 'smart arse' developer using an inappropriate hashing algorithm prone to collisions on large amounts of data. Even worse, another developer didn't think it was their responsibility to know about such flaws.
If you don't understand what the functions you're using do, don't use them! Looking up the trade offs with cryptography and hashing is a minimum standard, as is checking if a function is thread safe, or has any other documented issue. Know when to write functions yourself, and when it should be left to a third party library (cryptography, anything to do with times and dates).
Each and very US company will have received a NSL, take that for granted.
There are by far too many "forgotten" hardcoded admin credentials and other faults clearly intended as backdoors.
But to address this issue is clearly off-limits.
NSLs cannot force a vendor to implant a backdoor. It can force a vendor to provide the data he already has collected.
But yeah, there must be an enlightened discussion about Lawful Intercept and about backdoors.
About Data Collections. In my opinion it is a Stasi-like technique to collect on proven harmless and unpolitical people. Security agencies must delete collected records if the target proves to be fully harmless and non political, non military.
Then make it "the maximum number of people agency can collect on is 1% of population". That will make them prioritise who is actually a baddy and who is not. Whenever they add a new target, they must wipe an entire "old" target of their choosing. They can use Least Recently Investigated as a quick algorithm.
I draw a big distinction between a vendor who does their best and issues regular product patches and updates and a vendor that ships an initial buggy release that never gets patched or updated, save for buying a replacement which has new bugs and security holes. The latter type of vendor is, I agree, a huge part of the problem.
The easy solution is to stop buying cheap Chinese and Asian CRAP that doesn't get properly supported. But people keep getting suckered by low prices. There are reasons those prices are so low...
Except that there are non-Chinese companies with very much similar problems. There should he criminal investigations and FINES for leaving hard coded access credentials inside routers and other IT gear. And yes, major vendors that essentially run the internet traffic !
Also, there is the nagging suspicion these backdoors had been created at behest of "security" agencies.
Good to hear Mrs Easterly now wants to clean this up. Does she have the backing of her "former" employers ?
Whenever there's a statement along the lines of 'X should do Y', it's either uttered (a) because the person who states it has no say or control in the matter, (b) they misunderstand the dynamics that lead to Y in the first place, or it is (c) virtue signalling.
In the first, repeating a well known need just confirms a modicum of domain expertise (on the problem, not the cause).
In the second, if they did, and cared, they would have worked on fixing it, rather than talking about it.
Instead of this, CISA could work to persuade companies to build secure software. (not having them pledge, persuade them, which occurs often behind closed doors).
But as-is, this reads to me along the same lines as someone in a G7 country with a big truck and 24/7 airco in a house built for active cooling watching a documentary about global warming and writing a long social media post. True, but besides the point.
They are different terms for different purposes. Safety is the protection against unintentional harm to humans. Security is the protection against intentional harm to humans. Engineering for safety is the norm in many practices. Engineering for security is not the norm at all. If someone wants to throw another person off a bridge then there is no substantial protection against it. Just some minor safety barriers for accident reduction.
Lawyers need reminded of this distinction sometimes too.
are against engineering for safety. Where other engineering disciplines have had heavy regulation for many decades, if not centuries, those were for safety rather than security. All the bleating that somehow software engineering has had is easy by not being punished for insecure code is missing the fact that security is not safety, and safety is not security.
If the bad guys can find and exploit the holes in code, why can't the company whose code it is? In-house whitehats, but not the programmers themselves--a different team. And if you don't have in-house people with that skill set, then hire some outside company that does.
And yes, I'm naive...
There could be regulation that the software vendor has to create an Exploit Award Pool (EAP) of (say) 1% of revenue. Whoever can present a working exploit would be awared e.g. 1/30th of the yearly EAP. Whatever has not been consumed of the EAP would go back to vendor at end of year.
Of course details must be hashed out. E.g. employees of the vendor would only qualify for reward, if they did not work on the code related to the exploit.
It looks like Mrs Easterly knows what about what she says
https://en.wikipedia.org/wiki/Jen_Easterly
BUT - how do we make companies actually use state of the art techniques such as
+ proper, strict input scanners
+ proper, input parsers with a well-defined, strict grammar
+ memory safety in scanner+parser and other external facing code ? (Memory safe STL would already be a gread improvement in C++)
+ mathematical proof of memory safety if C is used. See seL4
+ extensive fuzz testing. Documented fuzzing concept.
There should be regulations along the lines of
A) "Must comply until 2026, if software is to be used inside U.S.G."
B) "Non compliant banking/insurance/mission critical software is taxed at double VAT"
As a software engineer myself I recognize that we need proper and intelligent regulation. Just going on with the Wild West of the last 50 years does not cut it, though.
We need a conversation about useful measures, which are then written in law and regulation.
Defending and protecting the indefensible and the inequitable always leads to increasingly rapid and peculiarly stealthy popular failure across more fronts than there can ever be defences designed and made readily available for ......... therefore, pure simple, raw common sense suggests supposed intelligence bodies and agents refrain and resist and desist defending and protecting the indefensible and the inequitable.
Surely that is not difficult to understand even though compliance prove itself so evidently impossible for so many more than just the intellectually challenged, the mentally deranged, the subversively invested and practically moronic ‽
Is that you recognising and confirming the West is most prone and particularly vulnerable to that increasingly evident and despicable problem which they do continually appear to choose to ignore whilst just expecting and hoping it goes away with no solution to field, mentor and monitor, AC?
Tell me that choice non-reaction is not delusional and verging on certifiable madness and we will have to agree to disagree.
Very hard to fathom your grievance. If it is the mainstream madness of a plethora of Marxism(Feminism to Wokery), I suggest to simply stopping to consume mainstream media. Just make sure not to replace it by the stuff coming from other power centers. Go to a church, where you can find reasonable people. A small, independent, non corrupted one.
That is an insane level of victim-blaming. It is not okay to steal. Period. Full-stop.
It is not okay to steal your neighbor's car. It is not okay to rob a bank. It is not okay to steal whatever catches your eye from a store. It is not okay to steal data, or access.
The world wastes incomprehensible resources trying to stop degenerate wastes-of-skin from stealing absolutely everything with any value. Those thieves are the villains -- certainly not their victims.
I'm no longer in a position where I buy commercial software, but I still see licensing "agreements" that state that the software is provided as "use at your own risk". How widespread (if at all) are such clauses in commercial sofware licenses? If they still exist, shouldn't they be phased out as part of the shift from insecure to secure software?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
