Slashdot Mirror
The Peon's Guide To Secure System Development
libertynews writes "Michael Bacarella has written an article on coding and security. He starts out by saying 'Increasingly incompetent developers are creeping their way into important projects. Considering that most good programmers are pretty bad at security, bad programmers with roles in important projects are guaranteed to doom the world to oblivion.' It is well worth the time to read it."
The P.Eng has one thing right - we need 'software engineers' or 'computer engineers' that are liable for their work (and the company that uses them are liable for too).
If Microsoft's products are so good, why do they disclaim liability on it?
Of course it isn't just microsoft doing this either. The whole licensing thing. If a 'license' is supposted to give you the privledge to do or use something, then in most things you are completely liable for your actions. For example, I have a drivers license, I kill somebody it is my fault. If Acme's Nuclear Control Software 2002 goes faulty and blows up part of the states - they would probably claim no fault (bad example I know - special case currently probably).
What we see depends on mainly what we look for. -- John Lubbock Now search for that bug slave!
He read a few books on the subject, and summarized the most simple concepts in an article.
Nothing new here.
Head to Amazon and find some books
Software Project Survival Guide by Steve C McConnell (Paperback)
Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire (Paperback)
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks (Paperback)
The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, et al (Paperback)
A non-Windows system is not a guarantee of invulnerability, but keeping a Windows system is guaranteed to put you at risk.
The real world seems to agree with him on these.
The coders are still shackled to the management that are trying to push it out as soon as it compiles and runs.. management doesnt CARE about stability or security and sales/marketing doesn't even care if it works.
until you can get the COMPANY liable for their software claims. and make their claims open and public, not buried in legalease.. I.E. if you dont want to be liable for it not working then the packaging must state "MIGHT NOT WORK" on the front in big letters.
until then it will not change... not in commercial software anyways...
Do not look at laser with remaining good eye.
?????
While I have taken this out of context, its not worthwhile to dispense with systems coding issues - thats exactly where most security problems start and need to be stopped. Anyone can be safe in a sandbox.
I found 2 quotes particularly enjoyable:
Call yourself a computer professional? Congratulations. You are responsible for the imminent collapse of civilization.
and
The user is pure evil.
Very true and sometimes misunderstood bits of information.
Fully licensed blockchain psychiatrist
the real question that any developer needs to ask...
"What you need doing? Daboo!"
going back to minding my fortress now...
m-
You catch enchiladas by picking them up behind the head and holding them underwater until they don't kick anymore -VeGas
I used to work at a software house, and I noticed our code always adapted to whatever the organization cared about. When they cared about timeliness, we gave it to them, but the bug count went up. When they cared about a low defect rate, we gave it to them, but the volume of code (completed feature set) went down. When they cared about maintainability too, they got that, but app performance suffered.
Most competent programmers can probably make meaningful conributions to secure apps, especially if the efforts are led by good architects. Not everyone has to be the best. The only thing is, whoever is commissioning the software has to rank security (which includes a low defect rate) above timeliness and feature count. If that's done, most programmers can rise to the challenge.
Don't blame the programers. They're just adapting to their environment. They do have to put food on the table after all, so they'll do what their companies value.
It should be a crime to teach people C/C++.
High level languages like Ruby, Python, or even Java are strongly recommended for all new projects.
How about a high level, compiled language with static typing like Ocaml. More speed, more protection, and it's been officially certified as "The programming tool of choice for discriminating hackers".
Ocaml
# (/.);;
- : float -> float -> float =
This "technologist" is carrying on about bad programmers and security? Wow - I assume he's a seasoned professional with many large-scale projects under his belt?
With such trenchant insights as "Don't use C/C++"! "Don't use Windows!" "Watch out for user input"!.
Wow. How truly insightful. I'm not even going to bother pointing out the utter absurdity of claiming that using or not using C/C++ has anything to do with it, or the added security problems with using high level languages (do you trust the implementation?).
I'm just going to say I've had bloody poops with more useful information in them than this article.
Everyone knows peons don't care about security. They just go around doing whatever they're told to do. Half the time, they're just standing around because there's nothing for them to do. They are oblivious to security breaches... I can't tell you how many peons I've seen getting hacked to death without them even noticing! And if they do notice, all they ever respond with is "Stop poking me!!!"
Peons, indeed
Nosce te Ipsum
I agree whole-heartedly with the first of 2 non-superfluous statements the author makes: Why do you think Java and, to a lesser extent, C# are so popular right now? ESPECIALLY for teaching? Because with Java and C#, it's very, very hard to write code that can break the system it's running on. I also agree to some extent with his position on cyptography...most serious (non-IE/Outlook) insecurities aren't based on cracked crypto - they're in buffer overflows, and weak points in code. I don't pretend to be anything but a pathetic first year java student, but I can see where this author is coming from just be reading this website once a week...
------- "From bored to fanboy in 3.8 asian girls" ----------
Wouldn't your wife's in-laws be your parents?
Sorry, couldn't resist... :-)
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
It should be a crime to teach people C/C++.
This guy is a little rough I think.
High level languages like Ruby, Python, or even Java are strongly recommended for all new projects.
This sentence should be continued "..for mediocre programmers.". Professional experts should use whatever language they are best at as long as it's reasonable for the project.
This article looks like he's giving advice on how to take a group of wanna-be progammers and try and get useful results from them. I think that's the wrong approach. What you should do is hire real experts. That way all the wanna-be programmers won't be able to get jobs and so they might realize "hmm.. maybe I should go back to school and get some real skills". Then we wont have as many of the problems that this guy talks about. Though maybe the schools aren't teaching the skills properly, but that's a different topic.
Aw crap, ninjas!
I guess you shot out of the womb with coding skills (doubtful). Everyone has to learn in their own way. In the end if someone wants to learn to program well, they will. Otherwise they'll just coast along until it's required.
I was a shitty programmer out of college and after moving between various jobs I learned along the way.
Business works by getting the most for the least amount of cash. Unfortunately most businesses don't have competent managers that can tell the difference between anything applicable in the real world and a buzz word they just read on CNet (most technical conversations are over their heads). That is my experience anyway.
During the 1980s, I developed software for ICBM command and control systems and for ICBM targeting. One of these systems ran on a Rolm 16-bit computer and was programmed in Jovial, assembly and Fortran. At the time, this computer was already 5 to 10 years behind the commercial state-of-the-art. However, it worked and almost all of the bugs in the computer and the compilers were known, and THAT is the key to developing secure software.
Don't use the latest and greatest. Use something that has been in production for several years and has had the bugs worked out. The military used to do this on critical systems. Did I hate coding in Jovial on a machine that only had 64K? Yes. But I also knew the machine inside and out and had hand-checked the compiler's assembly code generation to make sure that it wasn't doing silly things. It didn't, because 5 years in production had wrung out all of the bugs.
You know, theres something to be said for ignoring articles written in a degrading way towards its audience. It does make an interesting read if you imagine the comic book shop guy from the Simpsons was the author... worst article ever...
The article is a nice read, but it is obvious that the author have little experience in commercial software production.
Quality and security of a commercial software product is a financial decision, not a technical. Much like how software architecture is a strategic and not a technical decision, which many software developers do not realize.
When the cost of continuing to improve quality and security exceeds the income from support contracts, you have to draw the line. If you don't provide or charge for support, you draw the line when your investment exceeds your targeted income projections.
There are software products that are secure and virtually bug-free, but you and I can't afford them. They run nuclear plants, space shuttle command centers, etc etc. Hundreds of millions of dollars have been spent on that software, and it is not a question about "the user is evil". It's about having a thorough and mature development process and organization, preferable at CMM level 5.
So, I really don't know where the article would apply. Maybe when writing simple VB games for your website. Absolutely not when writing commercial grade software.
Oh, I can't help quoting you because everything that you said rings true
Qualifications?
Let's see...
Wow! Pretty exceptional, don't you think?
'bout the only thing going for the guy is he *doesn't* have a blog...
How the f*ck did this nonsense get put up on /. anyway?
What changed hands to get this deal done?
t_t_b
I'm on PJ's "enemies" list! Are you?
Most programmers graduate from state universities with no real-world experience in security, hacking, and so forth and no connections to anything that's going on -- it's simply a pass from the university of a student molded from the dirt-poor standards of a mainstream college system to a corporate programming world of laziness and no liabilities.
However, these people who are no more qualified to write code than a third worlder with no previous formal schooling trained to be an H1B in a cert mill -- yet are paid much more, for no good reason.
If anything, regular programmers who would ever, for example, use PHP's fopen() for a proxy like the article described should be paid like H1Bs and school teachers -- about $35,000 a year, at the most.
However, the ones who really know their shit -- like Mr. Bacarella -- should be the ones making $100,000 a year or more.
Why do you think Java and, to a lesser extent, C# are so popular right now? ESPECIALLY for teaching? Because with Java and C#, it's very, very hard to write code that can break the system it's running on.
It's also very hard with C/C++. The most you break on any system without very broken protection-handling is the faulty program itself.
The reason Java is taught as an introductory language is that it was stylish about 5 years ago. The reason C# is taught as an introductory language is that Microsoft threw a lot of money at universities to teach it, and at marketing to attempt to make it stylish.
It boggles my mind that people in second-year programming courses at my university don't know what a pointer is, because it wasn't covered in their first-year programming course (which used Java).
Languages with built-in safeguards are great, if that's your primary concern, but programming courses in university are supposed to teach you about all aspects of programming that you might reasonably encounter. If someone graduates without knowing how to debug memory errors and then has to maintain a C++ program, God help us all. This is also why we're forced to learn Lisp/Scheme and exposed to Fortran at some point - exposure to the concepts is what's important.
As far as what's used in industry is concerned, first likelihood is whatever the shop has used for the past several years (anything from VC++/VB down to Cobol, depending on where you're working), and second likelihood is whatever the industry fad was when upper management was setting up specifications.
Horsehockey.
Bull fucking shit.
It should be a crime to *start* students on a protected environment like Java. Programmers who start on Java begin with less understanding of what's going on, because it sweeps too much complexity under the carpet.
I realize this argument was made for assembler when C was introduced. BUT! There was a massive shift between assembler and C, which is why that argument is not valid.
C and Java both have pointers/references. They both have functions, etc. But Java's references are hidden from the user, and most students don't have a clue about a reference.
Asm. vs. C was a big difference, but Java and C++ share so much, but Java sweeps all that complexity under the carpet. If a programmer who's only used Java gets into a C++ project, he'll fsck it up so fast it'll make your head spin.
It should be a crime to teach Java as a beginners language. It's not a bad language, but under no circumstances could it conceivably be considered a beginner's tool.
But you have to have a verified design. Actually MS does offer solutions like this, inderictly, with Windows Datacentre. With a Datacentre server you can get things like gaurenteed uptime and so on. What happens is you contact an SI that is authorised to sell it, and you work with them to design the hardware and software you are going to use. They build and test the whole thing, and then sell you a gaurentee with the system and service contract. You then can't mess with the system. You can't go and install whatever software you want, because the software might break the system.
Real verified reliable design are, by necessity, very unflexable. You have to verify all the components and make sure they work together to insure that one won't cause problems. You then can't change the components, with out reverfing.
This just doesn't work for a desktop, where the user expects to be able to operate the system as they desire. that means that peopel can, and will, find combinations of software adn hardware that will fail. Hence, a software company can't gaurentee reliability in that situation.
For example, try Common Lisp, Objective Caml or Ada (not that high-level, but not the worst idea if you care about security).
Programming can be fun again. Film at 11.
You don't need secure clients, you only need secure servers.
Tell me, what is the compelling business reason for using windows that prevents me from using anything else in a corporate environment?
There is only one answer (or is it three?):
"Fear, Uncertainty and Doubt"
And that's one feature we can all do without!
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Using a high level language is the best kind of software reuse. The reason behind this is simple, chances are good that you are never going to be as talented as Guido van Rossum or Larry Wall. Nor will your data structures get as many eye balls examining them as Python lists or Perl arrays. Borrowing the work of the hackers that created some of these languages only makes sense.
Now, I am not saying that these programs don't have bugs, because they do, but I would bet that they have less bugs than anything you have ever written. So while using high level languages doesn't insure security, it certainly does help.
I've been wondering if there's much difference between C and C++ in security. C seems to be most used language for system and server programming nowadays, especially in Open Source projects.
C++ has many features that forgive your mistakes. With proper string, buffer, and other basic data type classes your bounds are always checked so there can't be buffer overflows which seem to be most common source of problems. In addition, automatic destruction of objects eases memory leaks.
You can, of course, do all the same things in C, but it's always syntactically more complex than in C++. You need to learn dozens of different coding rules just to avoid trivial problems. Often you forget to apply them; each time you create a risk.
For example, just today I noticed a dangerous situation when I initialized a callback function table with:While this works quite nicely, it's secure only if the struct always contains the two items. If a new item is added to the struct, all uses of the structure would have to be updated, but the compiler might not warn about this situation. In this case, the result would probably be a program crash. A more secure way would be:This is much safer. However, in C++, this problem simply wouldn't exist because structs are typically never used and classes have constructors that always initialize them properly and user doesn't have to care so much about possible changes in the classes.
This is just one example. There are plenty more.
On the other hand, stuff is more often allocated from heap in C++ rather than stack. Memory might therefore fragment more easily in C++ than in C.
that's the thing you see, trusting the client is plain wrong and assumptions made with that model will get you in trouble.
plan9 offers a model that doesn't require trusting the client. It runs a dedicated authentication server and a dedicated CPU server and a dedicated file server. The three talk to each other behind the client's back.
http://plan9.bell-labs.com/sys/doc/auth.html
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
From the article: "Considering that most good programmers are pretty bad at security,"
I don't necessarily accept this assumption. Most good programmers are good at coding up the design and requirements they've been given. The customer/architect/business analyst/technical lead needs to identify security requirements before they can be coded. It's very expensive to leave identifying security requirements to programmers. Not every project has the same needs. Sure, the programmer could guess. But each programmer on the project would end up spending a different amount of time and money on the security aspect if it's not clearly prioritized.
Likewise, if security requirements are not specified well enough, a security test-plan cannot be written or executed. If you need security, ensure it's somebody's explicit JOB on the project to ensure security gets into the design & QA.
Security costs money before a single line of code is written. Decide how much you need, where it's to be applied, and ensure it becomes a critical requirement through coding and testing. You can't expect security to just "happen" simply by hiring some "good programmers" as the author says.
It seems that Security aware coding is moving towards a situation akin to the bean counters that decide whether to recall a certain model of a car ...
People didnt set out to write insecure code. But usually thay have a set of requirements to meet in order to get paid. Apart from a few industries where large sums of money or human life were directly involved , meet the requirements ASAP and get paid...
Even "closed source" development projects have Quality Assurace processes where some dude checks your code (whether they know what they are looking for is another issue)...
But particularly with bespoke code, people write according to a set of requirements. "I want it to do this, I want it to do that..". If it doesnt I can sue/refund/get free upgrades, if it gets hacked by some snotty nosed kid , tough, that kid wasn't in your requiremnets. Security is not easily specified as a requirement and is hard to insure against (financially) .. so pretty soon you will see the emergence of "security support contracts".
This is the direction Micro$oft are going in ..
(sustainable revenue is good for any business)
Yes, there is a wide range of programmers with varying abilities. but (apart from open source products), certain companies have realiazed they can/will charge big bucks for more security oriented support contracts, so what do they care.
For non-opensource companies lack of security/defensive programming has changed from being a liability to a profit generator.
Either they'll make a lot of money or open source will prevail.
Also expect a lot of specialist code review/certification/QA companies to pop up
"This product is independantly DeadBolt certified"
and hence costs $30 more + $30 a year for the latest security upgrades...."
(multiply those figures as appropiate!)
When you critique someone's work, it is customary to first read it in its entirety. Besides the fact that it's just common courtesy, if you had read just one more paragraph you could've prevented yourself from committing such an egregious faux pas.
In other words; if you're going to insult someone don't reveal what a stupid twit you are in the process. Dumbass.
High level languages like Ruby, Python, or even Java are strongly recommended for all new projects. The reason these languages are more secure (in theory) is that they don't have pointers. Most security vulnerabilities that involve breaking program code involve manipulating pointers-in fact, many programming bugs are generally related to pointers in some way. As with the OS issue noted above, do not mistake this for invulnerability. You're simply less likely to be compromised using this particular attack vector with a high level programming language.