Forgot your password?
typodupeerror
Programming IT Technology

The Peon's Guide To Secure System Development 347

Posted by michael
from the mincing-words dept.
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."
This discussion has been archived. No new comments can be posted.

The Peon's Guide To Secure System Development

Comments Filter:
  • by kevlar (13509) on Friday November 15, 2002 @03:06PM (#4679048)

    They're just paying for what they get. I tend to believe that its not so much bad programmers as it is a general apathetic attitude that good programmers have now. If there's no incentive to bust your balls, you're not going to!
  • by Lumpy (12016) on Friday November 15, 2002 @03:11PM (#4679095) Homepage
    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...

  • Useless advice? (Score:3, Insightful)

    by Ars-Fartsica (166957) on Friday November 15, 2002 @03:11PM (#4679101)
    To quote "It should be a curse to teach C/C++"

    ?????

    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.

  • bad coders (Score:2, Insightful)

    by greechneb (574646) on Friday November 15, 2002 @03:11PM (#4679103) Journal
    When I look back at my programming classes in college, the majority of the people didn't have a freakin clue. I don't think most of them could install a program on their own. Unfortunately the teachers all walked them through it, and they ended up passing, because they had their hands held the entire way. Its scary to think that some of them could end up in high places.
  • by Max Coffee (559629) on Friday November 15, 2002 @03:16PM (#4679149)
    I really don't think the blame can be placed on the programmers here. Software development organizations get from their programmers what they measure and reward.

    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.

  • What hubris. (Score:5, Insightful)

    by ProtonMotiveForce (267027) on Friday November 15, 2002 @03:16PM (#4679155)
    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.
  • 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...
  • Re:bad coders... (Score:2, Insightful)

    by Max Coffee (559629) on Friday November 15, 2002 @03:22PM (#4679208)
    I suppose that's a factor, but most of the non-secure software in common use today was written during a mad expansion, not a recession. At that point, the issue wasn't cutting costs, it was getting products out the door before your competitors did, and left you in the dust. Ultimately, app security comes down to the company's priority list. That, in turn, tends to be driven by the priority list of the market as a whole. Most people didn't care at all about security until very recently.

    If the people care about security now, you can bet the companies that succeed over the next decade will be the ones that satisfy that demand.

  • Wrong approach (Score:5, Insightful)

    by lazyl (619939) on Friday November 15, 2002 @03:23PM (#4679221)
    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.
  • by BoomerSooner (308737) on Friday November 15, 2002 @03:25PM (#4679232) Homepage Journal
    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.
  • by varith (530137) on Friday November 15, 2002 @03:26PM (#4679242)
    You don't need to make engineers liable. It management (executive management to be precise) that needs to be liable. Hell I keep getting turned down on projects to improve the code in my company. The only way I could possibly put reeally good security would be to put 20-30 hours a week of my own time in - past the 50-60 I already work. No thanks.
  • by Anonymous Coward on Friday November 15, 2002 @03:27PM (#4679250)
    >High level languages like Ruby, Python, or even >Java are strongly recommended for all new >projects.

    All of these languages use a C program to
    run.(interperter, VM).

    First this guy suggest against useing
    close source components are components
    that you do not understand.

    Well, what are these high level languages that
    he is suggesting. There just a convinent
    ways to write C. (Java excluded)

    Maybe he thinks that you should read through
    the ruby and python source before you
    start using these languages?

    I think he's suggestion is the reason
    we have bloated unsecure software,
    everyone trust that there languages
    is in a little black box just because
    it has a VM. What if the VM has a security
    flaw, isn't this just like running a
    secure program on top of windows.

    Just keeping a developer from using pointers
    is no way to insure a projects security.

  • by DoctorMabuse (456736) on Friday November 15, 2002 @03:27PM (#4679251) Homepage
    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.
  • by j_kenpo (571930) on Friday November 15, 2002 @03:27PM (#4679256)
    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...
  • by Hamstaus (586402) on Friday November 15, 2002 @03:28PM (#4679260) Homepage
    If something like Windows plays any part at all in your system design, you should probably give up now. Despite being closed source, holes are discovered constantly.

    I hate to break it to this guy, but this article is basically a big rant of his personal opinions. Not that I have anything against that, but I feel anyone heeding this person's advice unerringly would be making just as big a mistake as if they didn't listen to any of his advice.

    Open-source, closed-source, it doesn't goddamn matter. The fact is, code is written by humans, and is therefore imperfect. Realize that now and save yourself a lot of time. Open-source continues to have just as many flaws in it as closed-source. How many times has the bind package been updated in recent memory? And don't start the "many eyes" thing again, we all know it and we're all tired of it, and I realize open source gets fixed faster.

    My point is, when I first got into Linux, I took a default install of Red Hat and threw it on there. I had read all sorts of advice that if I wanted a secure server, I should use *nix, so I did. Yeah... rooted. Rebuilt the box, using a way newer distro... rooted. My failing was trusting the code implicity based on what other people said. Old versions of open source stuff are just as vulnerable as old versions of closed source stuff! And you know what? I guarantee that this will always continue to be true.

    Constant vigilance is your only safe-guard. The open-source/closed-source argument is secondary to this. If you can build, deploy and maintain a closed-source based system much easier/cheaper/faster than an open-source one, well, balance that against your security requirements.
  • by ACNeal (595975) on Friday November 15, 2002 @03:29PM (#4679269)
    The problem with this is that the whole system has to interoperate together. The system is only as secure as the total of all its components working together.

    You can say the same thing for a bridge. It will only stand if all the parts of construction are good, which the developer (not the engineer) are in control of. If the design is inherently flawed, the engineering firm will liable. If the construction is flawed, the developer is liable.

    The difference between software and your analogy is that the engineer/developer has complete control over the whole system. Developers don't. Microsoft doesn't. If the user of that same bridge goes and replaces all the rivets used, the developer can hardly be blamed when the bridge fails because of this.

    If I build a huge structure right in the middle, and you build another, and CowboyNeal builds a third, much smaller building, and suddenly the bridge collapses, whose fault is that? The bridge developer? Me for starting the trend? CowboyNeal even though his was the smallest?

    and then when we bring security into play, that is a whole different ball game. The engineer doesn't have to worry about people activly trying to make his bridge fail. If someone (say a tterrorist) plants shaped charges to destroy the main supports, and the bridge collapses under its own weight, no one would even think about sueing the engineer (except for maybe the lady that dumped coffee in her own lap, and somehow thought McDonalds was at fault).

    In software systems we rely on everyone else to be well behaved. We also rely on the combination of everyone elses systems not interfering with our systems in unexpected ways. A system of mine could run fine without a single crash. A system of yours could run without a single crash. Together they might get spurious crashes. I have never had a crash on a fresh install of Windows while playing Freecell before I install anything else.

    The same idea of liability can't be applied to software systems.
  • by bigmouth_strikes (224629) on Friday November 15, 2002 @03:30PM (#4679275) Journal
    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 [cmu.edu] 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.
  • by talks_to_birds (2488) on Friday November 15, 2002 @03:31PM (#4679280) Homepage Journal
    Surf to his web site [bacarella.com], and it's just the same old self-absorbed bullshit that so many other people put up.

    Qualifications?

    Let's see...

    • I was born on August 28th 1980, 4PM in Long Island.
    • My life was pretty aimless until I broke my arm in the 8th grade, keeping me from most sports and physical activity. That's when I discovered the magic of computers. I haven't stopped poking them since.
    • My chief interest is in information science (ie, computers). This interest involves my day job, my business, and most of my recreational activity.

    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

  • by aero6dof (415422) <aero6dof@yahoo.com> on Friday November 15, 2002 @03:32PM (#4679284) Homepage
    If Microsoft's products are so good, why do they disclaim liability on it?

    Because the customers don't want to pay the added cost of reliability beyond what they need. If you want absolutely, positively bulletproof software, you're going to have to pay a higher development cost (mostly in testing, but in extra liability insurance for the company too). For safety-critical applications, customers are willing (or should be willing anyway) to pay for the additional cost , but it's ridiculous to pay for it when you don't need to. Do some googling on the cost of the space shuttle software for instance...
  • by VegetariMan (162508) on Friday November 15, 2002 @03:43PM (#4679367) Homepage
    Let the flames begin!

    Honestly, I applaud open source. I think it can be quite a boon to the rest of the world. However, I've definitely seen enough public code that looked like it was written by a wannabe compsci major. It's nice to see this topic discussed. Open source is a powerful tool, but without good management and high coding standards it's just broken source.
  • Re:Useless advice? (Score:5, Insightful)

    by Subcarrier (262294) on Friday November 15, 2002 @03:43PM (#4679369)
    He's contradicting himself here:

    You can tell the difference between a developer who gets it and one who doesn't because the developer who doesn't get it is content to build a custom system using closed source components that they cannot understand, let alone keep secure.

    when he goes on to say that

    High level languages are usually more secure than C/C++ ...

    High level languages are built on layers and layers of things written by other people, things that you know nothing about. If you use C or assemlber, you're much more likely to be in control of the security of your code.

    I guess the comment about C/C++ is aimed at coders who suck more than average; they're certainly better of using code written by other people.
  • by SexyKellyOsbourne (606860) on Friday November 15, 2002 @03:43PM (#4679370) Journal
    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.
  • by NullProg (70833) on Friday November 15, 2002 @03:43PM (#4679377) Homepage Journal
    I agree, what mindless drivel. All rant and no facts.

    Quote:
    It should be a crime to teach people C/C++.

    Then further into the article:
    Whenever possible, use industry standards. For example: POSIX, ANSI C, OpenGL, SQL, etc. Resist using non-standard extensions, if you must have them, keep them limited.

    I feel for his clients. Slashdot blew it on this story.

    Enjoy,
  • by ProtonMotiveForce (267027) on Friday November 15, 2002 @03:44PM (#4679382)
    I'd like to see someone, just once, say "He's right. I'm a bad programmer and I do these things sometimes. My co-workers are much more competent than I am and maybe that's why, because their code is over my head."

    But noooo. It's always "the other guy" and "the place I used to work", etc... Bah.
  • by aero6dof (415422) <aero6dof@yahoo.com> on Friday November 15, 2002 @03:49PM (#4679417) Homepage
    I agree with you and would go a little further. Its not only their internal company environment, but the environment of market too. Unless customers are deciding to purchase one product over another due to its security features, software isn't going to get more secure.

    Look at airbags in cars, the government doesn't mandate side impact airbags, but some manufacturers put them in anyway because it's a selling point that some of the customers care about.

    Now, I'm sure someone is going to point out that maybe we should have gov't enforced minimum security standards. However, I'm skeptical that government would be capable of doing it sanely right now.
  • by sien (35268) on Friday November 15, 2002 @03:55PM (#4679444) Homepage
    Looks like the editors just got trolled. 'Netgraft' indeed. Perhaps this guy is a mate of the Afghan with a C64 that so intrigued Katz, speaking of which, what happened to him ?
  • by Christopher Thomas (11717) on Friday November 15, 2002 @03:57PM (#4679458)
    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.
  • by VT_hawkeye (33442) on Friday November 15, 2002 @04:02PM (#4679501) Homepage Journal
    When all these half-trained Java-based "CS major"s have to deal with real systems of all types, including those that require memory management by hand?

    This is precisely why Java and C# SHOULDN'T be the primary teaching language at any serious institution. It doesn't just encourage bad habits in memory management, it breeds ignorance of the CONCEPT of memory management. I'm extremely glad I had a good background in C/C++ (and even some Pascal before those) before I ever learned Java or Python, or I wouldn't have a clue about half the concepts that a good C background forces you to learn.
  • by vendull (4435) on Friday November 15, 2002 @04:03PM (#4679510)
    Schools are teaching languages like Java and C# because there is so much hype surrounding those languages.

    IMO, this is part of the problem. Languages should not be taught. concepts should be taught,a nd those concepts will translate to any language. People are coming out of schools having only been taught in Java (C# / whatever) and have no concept of things like memory management, buffer overlows etc. These folks have never had to think about these issues before because they only wrote Java code in school. When these people get out into the industry, they will almost certainly have to maintain some code at some time that deals with issues like this. Sorry, but the world doesnt revolve around all of these high level languages yet. There is a lot of C/C++ code out there in the real world that will need to be maintained for many years to come. We haven't managed to kill off COBOL yet after all :).

    Also, as others have mentioned, coding in these high-level languages can give you a false sense of security. Do you trust your Java implementation for example? Are you willing to say for certain that the JVM doesnt have any buffer overflows in it :).
  • by ProtonMotiveForce (267027) on Friday November 15, 2002 @04:03PM (#4679512)
    The offensive part is the platitudes. It's one big general diatribe on nothing at all. Reminds me of the preachy father from Hamlet - all words and no content.

    Is his point that people need to be more serious about security? Fine. But he's utterly unqualified to be giving technical advice or making technical judgements on a field he obviously knows nothing about (use Python, Ruby, or Java and never C++? I call buzzword bullshit bingo!) other than the vague general knowledge a "technologist" would have.

    It's like me saying plastic surgery has become dangerous because there are so many quacks, and they all need to sharpen their scalpels and pay attention to sterility.
  • by Pyromage (19360) on Friday November 15, 2002 @04:21PM (#4679647) Homepage
    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.
  • Not only that (Score:3, Insightful)

    by Sycraft-fu (314770) on Friday November 15, 2002 @04:26PM (#4679692)
    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.
  • by __past__ (542467) on Friday November 15, 2002 @04:31PM (#4679734)
    There's a simple solution to both the problem of hight level languages being "just a convinent ways to write C" (and I don't see why one should exclude Java here, but I don't think that this argument is valid anyway) and them being slow. Use high level languages that don't run in a C-based interpreter. Duh.

    For example, try Common Lisp [cons.org], Objective Caml [ocaml.org] or Ada [gnat.com] (not that high-level, but not the worst idea if you care about security).

  • by DrSkwid (118965) on Friday November 15, 2002 @04:33PM (#4679754) Homepage Journal
    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!

  • Make up your mind? (Score:2, Insightful)

    by kelcey (626524) on Friday November 15, 2002 @04:35PM (#4679770)
    Earlier in this article, we see the inflammatory statement: It should be a crime to teach people C/C++. But later in the very same article: Whenever possible, use industry standards. For example: POSIX, ANSI C, OpenGL, SQL, etc. Beg pardon? If we use C or C++ (industry standards, I believe), should we then be imprisoned or lauded? Or is it just possible that the author is getting a little carried away with himself? "Programming languages without mandated security don't break systems. Bad code written in programming languages without mandated security breaks systems." Kelcey
  • by Jason Earl (1894) on Friday November 15, 2002 @04:38PM (#4679791) Homepage Journal

    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.

  • by Anonymous Coward on Friday November 15, 2002 @05:01PM (#4679967)
    There is no system that is invincible, but with some simple adjustments you can come very far in achieving a high degree of security, which has other positive side effects to boot!

    If the "adjustments" are so "simple," why didn't the author bother to explain a few of them? Porting a large project from C++ to Java is usually not an option. Replacing Windows with some other platform is usually not an option. And using a lot of foul language doesn't do a thing to explain the matter or increase the security of anything.

    My guess is that this guy is working on a project or projects with lots of security holes, and he has written this "article" so that he can point to it later and say "See! I told you so!"
  • The Humans (Score:2, Insightful)

    by 3fthiandrising (626526) on Friday November 15, 2002 @05:04PM (#4680004)
    This is missing the point. Security is not a destination to be reached, but a room tempature set to the preferences of the occupants. Do you ever lock your car doors when driving through the bad part of town? Do you think that we secure our homes the way we want our airports secured? Can you not acknowledge that we all tolerate specific levels of risk in many areas of our lives? Some one had a great point when they pointed out that Nuclear power plants, the space shuttle, ICBM warz are all very secure and mature systems. Do you really think that when Joe Bloggs starts designing an autopart inventory control system, that he is thinking about preventing unauthorized access to the extent of a powerplant? Or that the building engineer for a 12x12 parking lot PhotoMart cares about making his hut as difficult to enter as a bank?
  • by ergo98 (9391) on Friday November 15, 2002 @05:20PM (#4680112) Homepage Journal
    I happen to be an engineer, not because of an economic barrier, but because I managed to study x years in a University.

    Yet plenty of people study >x years in University and don't get a P.Eng, yet suddenly they find barriers to their professions by arbitrary membership rules. If a professional engineering designation is a signal of education, then isn't that amply filled by existing programs?

    And since you are in Ontario, which is where I got my engineering degree you should know that money is not the issue to getting an education.

    No, but it's job mobility. John pursued advanced computer monkeyology and then became an expert software developer in the field of Monkeyology. Jim went through and become a "P.Eng in Computer Software", knows nothing about Monkeyology, but you're saying that John should be barred from writing software as Jim is certified? _BS_ It is a barrier of job mobility specifically to maintain exclusivity for its members. The P.Eng is trying to get its greedy hands into software development (as a mandatory element of software development, rather than a "marketforce" certification much like an MCSE or Cisco certificate), and they won't have a chance in hell.

    Also engineering certification does not mean quality. It means that you studied so many years and have gone through specific procedures. Just like police people and fire people. Some police people are good and some are baffoons, but regardless you know that they have gone through police trainning....

    Total agree with you here (and it's common for any certification/degree/diploma), but then you say...

    You just need enough engineers to sign off legally on designs

    Now that's just offensive. So we have some people who have joined the exclusive club, and now they have special rights and responsibilities to look over us common folks? I have known a couple of P.Eng's who were the dumbest (literally), laziest people I've had the displeasure of meeting (note that I'm not saying that all P.Engs are. Indeed, the same group includes some of the most honourable and brilliant. My point is that the membership in and of itself means exceedingly little), but suddenly these people are a signing force for a passport? How ridiculous is that. Don't tell me about the great responsibility they take by signing something, as the same holds true for ALL OF US: We all can have careers ruined, lawsuits, criminal complaints, etc, if we sign off on something negligent, incompetently, etc.
  • by bahwi (43111) <incomingNO@SPAMjosephguhlin.com> on Friday November 15, 2002 @05:26PM (#4680154) Homepage
    An infiltrated client, considered trustworthy by the server, if a break-in of the server. Thus, to secure a server you must secure your clients. Whether it be an overflow in IE that installs a key recorder and gathers the passwords to the server of an encrypted e-mail system. Suddenly you have access to that users e-mail, and all outgoing e-mail can "come" from that user. Secure clients are as necessary as secure servers.
  • by dstone (191334) on Friday November 15, 2002 @05:29PM (#4680200) Homepage
    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.
  • by ydrol (626558) on Friday November 15, 2002 @06:04PM (#4680928)
    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!)
  • by fferreres (525414) on Friday November 15, 2002 @11:26PM (#4683227)
    In fact, you are trusting the client. Not blindly trusting it, but if you provided this client then they will blame you. And if you didn't provide the client (say IE) then you allowed them to access your services through an unsecure client.

Remember, UNIX spelled backwards is XINU. -- Mt.

Working...