Security Engineering

SilverStr writes: "With all the recent discussion on organizations rethinking their security strategies, I thought I would do a review on one of my favorite books. I have stayed pretty quiet on /. over the years, but security is something I don't think developers anywhere should be taking lightly. Hopefully some of them will get something out of my review and pick this book up." Read on for the rest of his review of Ross Anderson's Security Engineering. Security Engineering: A Guide to Building Dependable Distributed Systems author Ross Anderson pages 612 publisher Wiley Computer Publishing rating 9.5 reviewer SilverStr ISBN 0-471-38922-6 summary An exceptional book on the dynamics of security engineering. A must have on all developers shelves who care about digital security and its impact on system design.

Introduction

The complexities of security engineering go beyond the ideals of understanding buffer overflows and considering that patching your systems is not an option. Many a Slashdot article (particularly the latest one on Louis Bertrand's OpenBSD presentation) has comments on the failings of code design. In Ross Anderson's book Security Engineering: A Guide to Building Dependable Distributed Systems, Ross goes into impeccable detail into the aspects of building systems resilient to malicious attack, abuse and programming error.

The book is well laid out, and in my opinion Ross properly segmented the topics in a way that makes the sections easy to read. The first section is focused on the many concepts of digital security such as protocols, access control and cryptography, and is written in a way so that you do not require a technical background to understand. It was refreshing to read how Ross explains cryptography in such a non-threatening manner that you can understand it without having to refer to Applied Cryptography from Bruce Schneier. Many authors have tried this in the past, and failed.

The second part of the book goes into considerable detail about practical and important applications such as banking and network attacks and defense. I have to be honest with you, I don't read a lot of books on software engineering that go into Radar Jamming and Nuclear Command and Control systems, and I found that sort of discussion exciting. (Although I have no interest in writing security code for the next cruise missile that will move the world to a level of DefCon quicker than that in movies like War Games, I still was quite interested in the approach.) Many of the examples and case studies that Ross explains bring the whole topic together to help strengthen the point about security engineering and its application to each system. Further to this, Ross' writing made me shutter to think about just how popular applications like bankcard systems have been written to be so weak and vulnerable. Before the book's main content, Ross includes an explanation the legalities of publishing some of this information. It wasn't until I started reflecting on some of the case studies that I realized how potent and valuable some of this information is, especially when I thought of potential risks that should have been mitigated and were not. Ross' examples should be considered textbook cases, though, and not information that can be drastically abused.

The third part looks into the organizational and policy issues faced with security engineering. From office politics to security and the law, this section goes into depth about managing security engineering and its affects on business and people. Compared to the rest of this book I found some of the topics in this section too short on detail, feeling like just a glancing blow, but still giving the reader enough information to seek more in depth content if they so choose. (Check out the bibliography for such information.) Discussing issues such as Carnivore, digital copyright, and system evaluation and assurance, this section rounds out the book quite well.

Why to Consider this Book

If you are a developer considering security (which should be all developers, anyways) this book provides a good balance on security engineering, and serves as an excellent reference work. It can work well as a textbook introducing developers to security engineering, and can be used as a good introduction to many dynamics of digital security. (Hint to COMP professors outside of Cambridge: get your students to read this book -- after you do of course).

Although you might not be able to use the section on radar jamming and its countermeasures directly, you may still be able to use principles in writing protected electronic systems while working on that new wireless system for Ma Bell. And finally, you should use this book as a brick in the foundation of learning on the concepts of writing secure code.

Something else you should consider in this book is the extensive bibliography in the back. If you want to follow up with more detailed information in any one section, Ross did an tremendous job in providing pointers to research papers and work done by others to read and research on. This in itself made the book well worth the money, as for me I have already read up and used some of the works I didn't have indexed to me before.

Wrap Up

If you are going to read this book and look for samples to write secure code, you are going to pick up the wrong book. This book is a cornerstone in building a strong foundation and understanding of security engineering. This book is goes beyond understanding the practical components of buffer overflows, stack smashing and code audits for review, and takes the reader into a new plain of understanding when it comes to security engineering. It is not a cookbook for lazy script kiddies to learn how to attack weak systems, but can be used to allow you to learn from others mistakes. You don't have to be a developer working on security systems to gain some knowledge from this text. Areas in the book such as that on E-Commerce can very much help bridge the chasm of bad web application design and can help you refrain from getting in the trap of fast application development full of vulnerabilities and exposing users to unnecessary online risk.

It is the responsibility of all developers to understand the risks they expose their software and their clients to. I am sure some developers will have some excuse where their web forms and applications do not require them to learn such silly things. That's fine. Hopefully I wouldn't need to use your systems. For the rest of us though, this is a must read.

Table of Contents

Part One

1. What Is Security Engineering
2. Protocols
3. Passwords
4. Access Control
5. Cryptography
6. Distributed Systems

Part Two

1. Multilevel Security
2. Multilateral Security
3. Banking and Bookkeeping
4. Monitoring Systems
5. Nuclear Command and Control
6. Security Printing and Seals
7. Biometrics
8. Physical Tamper Resistance
9. Emission Security
10. Electronic and Information Warfare
11. Telecom System Security
12. Network Attack and Defense
13. Protecting E-Commerce Systems
14. Copyright and Privacy Protection

Part Three

1. E-Policy
2. Management Issues
3. System Evaluation and Assurance
4. Conclusions

Bibliography

You can purchase Security Engineering from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Comments

Speaking of security...

[ksw2]

This reminds me, looks like the speeches from Defcon 9 will be going up online soon.

Sugaring the pill

[GSV NegotiableEthics]

Let's face it, most developers would rather gnaw their own left leg off than read about something as dull as building secure systems--it's so often something left to a security audit or (even more often) a malicious cracker to discover the inevitable vulnerabilities. So it's nice to see a book that capitalizes on the glamor of nuclear defence systems to try and kickstart interest.

Any books w/sample code?

[zapfie]

If you are going to read this book and look for samples to write secure code, you are going to pick up the wrong book. This book is a cornerstone in building a strong foundation and understanding of security engineering.

If one was looking for a book with samples of writing secure code, does anyone have any recommendations?

Re:Any books w/sample code?

[jsmyth]

If one was looking for a book with samples of writing secure code, does anyone have any recommendations?

http://www.openbsd.org/slides/musess_2002/index.ht ml

This website gives a few tips on avoiding the main pitfalls of insecure coding, including how to avoid buffer overflow exploits.

Re:Any books w/sample code?

[Snake]

If one was looking for a book with samples of writing secure code, does anyone have any recommendations?

I heartily recommend the book Building Secure Software (How to Avoid Security Problems the Right Way) .

It also shows that security is mostly a human problem.

On the other hand, I would like to know how crackers find security holes. For example: how was the buffer overflow in PnP XP found? Did the guy sort of fuzzed it?

What I mean is: Before trying to secure software, it would be nice to know how the bad guys (or the security researchers) find the weaknesses.

Re:Any books w/sample code?

[joib]

I haven't read the book, but for something with a perhaps more practical approach, check out the Secure Programming for Linux and Unix HOWTO.

Re:Any books w/sample code?

[5skin]

This book doesn't really have any code in it. Building Secure Software has plenty of code.

Re:Any books w/sample code?

[Suicyco]

There are many good articles on how to do this. Check @Stake and securityfocus. In essence, a typical buffer overflow is discovered by hammering away at software until you can reproduce a bug, by making the software crash. You then reproduce this crash using a debugger such as softice, trace the stack and figure out just what is going on memory. You then craft your input strings to hijaak the registers to point to a different location to begin executing code.

A good example is: http://www.atstake.com/research/reports/wprasbuf.h tml

Its a simple exploit of RASMAN.EXE and takes you through step by step how an exploit is discovered, researched and ultimately exploited. Its an interesting subject to say the least, but not for the faint of heart. Brush up on your assembly!

Secrets and Lies

[ksw2]

He mentioned Applied Cryptography... I wanted to point out Schneier's latest book Secrets and Lies, kind of a real-world threat analysis in contrast to the mathematical analysis of Applied Cryptography. Good read.

Secret Lies by Bruce Schneier

[Anonymous Coward]

Another book which is even more accessible to non-techies (perfect for clueless CEOs and management in general) is Secret Lies by Bruce Schneier. An excellent high-level view of why security often is sub-standard in most organization and many useful discussions on what to do and not to do with regards to security in general. Every man and woman should read this excellent book!

We need more disciplines like this

[Dr. Bent]

Software development, on the whole, is not practiced as an engineering discipline. It needs to be. Software engineers should be certified just like civil engineers or electrical engineers, and when something breaks, the company shouldn't be able to hide behind the EULA...they should be fully accountable.

This would make software much more reliable and siginificantly reduce the maintence cost for users.

Re:We need more disciplines like this

[GSloop]

I don't know about the certification bit...perhaps it would be a kudo, but not a requirement...hmmm...

But I do agree with the engineering approach. (By the way, I'm not an engineer, but the much maligned Business School - Information Systems graduate)

Software design, and the structure over the programming/QA/design teams seems really weak to me. To get a good program (virtually bug-free and good security...realize that these are one and the same) the structure must be quite rigid. We can't all go off coding as we wish, and just throwing the design and QA portions together on the fly.

I know I mentioned it before, but Mark Minasi's "The Software Conspiracy" is a great book that lays out these principals in overall detail. Look at the references to find more concrete/detailed examples of structured coding and design.

If we ever expect to get decent software, and secure software, we must then take a more rigorous and structured approach to software creation and design. Until this gets done, we'll all be running around in FRONT of the 8 ball trying to patch things after the fact. I can attest that this approach is a loosing one - in any disipline. Security has to be built in up front. Writing good code, and having a very structured devlopment environment need to be carefully engineered.

If we built bridges the way we build software, about 30% of all bridges would catastrophically fail. Now, you'll say, "oh software isn't as important, or at least not most software." Well, sure, that's true. But I don't think the reason we build good bridges the first time is because it could kill someone - although it's probably one of the reasons. The most likely, is that REBUILDING bridges when they fail is very expensive. When that happens, we know who to blame, and the following costs are very apparent.

What happens in software, is the costs are not tracked and traced to their source. If they were, we'd all of a sudden realize that the cost of crappy software is HUGE! I don't recall the source, but I think the estimated cost of the NIMDA virus was like 2 Billion. Lets assume that the cost was over estimated by 100%, so the real cost was only 1 billion. We're talking about some real cash here. I don't know what Windows developemt costs were, but I'd bet for an extra billion, and some real care to fix the problem, we could have had a whole lot better software.

Now finally for the market based solution. Make vendors liable for the bugs and insecurity of their software The government doesn't have to mandate a standard. A jury decides if the software vendor used due dilligence in writing good code. All I'm asking is that the atrificial protections for software be lifted. Treat it like any other good. We wouldn't expect the same functionality or lack thereof for our lawn-mowers, toasters, cars, microwaves or even our Tivo's.

When vendors find that the real costs get shifted back to them, in the form of civil negligence suits, they'll get serious about fixing the problem. Until then, they'll laugh their way to the bank, and we (the techs) get to fix the problems over and over and over again. Not only that, but WE look bad, rather than the vendor.

Ok, do your damage.

Cheers!

Re:We need more disciplines like this

[Drakula]

Not to criticize you post, because I agree, but Electrical engineers are not certified. There is no certification process besides the Bachelor's degree that is required, or even available I believe, in order to work. I think Civil and Mechanical do require something depending on the type of work.

I agree though, some formal certification/education program should be developed for general system administration and especially for security specialists.

Re:We need more disciplines like this

[Anonymous Coward]

But the acquisition costs would skyrocket - producing solid code is extremely hard to do and is quite time consuming. Software engineering is not directly comparable to other engineering disciplines. Faults in phyical materials can be compensated for in the design and there is more understanding of how to create designs with margins of error. Not so with software.

The analog world can tolerate limited failures such as cracks in concrete with out causing catastrophic failure of the entire system, software cannot - a single typo can cause the entire program to fail.

Re:We need more disciplines like this

[CrosseyedPainless]

At the current state of the art, software engineering is about as codified and scientifically verifiable as medicine was in the 12th century.

Re:We need more disciplines like this

[einhverfr]

The only problem is:

Engineered security is and should be intuitive. It is not a matter of difficulty in the actual engineering process but rather a lack of effort that the software engineers devote to the process. This is pretty simple for most pieces of software with the main exception being cryptography (which should be far more rigorous than many engineering disciplines).

When I have designed secure distributed applications, I have generally carefully considered what level of trust to give each component and then layered the security accordingly. I can then delegate out the security-related tasks to the operating system, database manager, main application, etc. as appropriate so that a security failure in one module in no way is a complete system compromise (can you tell I don't like IIS or Sendmail?). In short, I design my applications with the idea that they will fail, but that such failure will not be complete, and then do what I can to prevent the failure in the first place.

To me this is pretty simple and straight-forward and does not require an engineering degree. What it does require is a little forethought, and the humility to realize that as a programmer, no one is perfect.

Re:We need more disciplines like this

[SirSlud]

I agree to a point. The software world is dangerously sales-driven (My uncle coined the term "Real Time Sales Driven Development", or RTSDD for short. It makes extreme programming look like a gentle stroll through the park.), and defiantely could do with some professional ceritifcation regulations that slow down the clamour to develop the latest buzzword. To some degree, I'm sure the situation is much better at insitutions that have used software systems for many years (ie, banks, etc) than consumer-facing industries ('net access providers, ASP providers, OS *cough* vendor). The CS degree seems to be how companies evaluate the 'professionalism' of a programmer, but I think its a misplaced faith. More important than that would be audits and guidelines that must be adhered to by a regulatory body.

Of course, those addicted to the worderful world of 'slave-to-the-market innovation at the speed of e-business and shit' probably shudder to the thought, but can you imagine if designing buildings were subjected to the kind of rush-out-the-door development tempo that many dev houses have? Sure buildings have people, but softweare systems hold processes and business logic, which surplanted people long ago in terms of marketplace value.

It'd probably result in greater long range vision for the software industry as a whole as well.

Re:We need more disciplines like this

[GSloop]

Read above you...

What I think you and others like you misunderstand, is that the current system of not having good code is really expensive too.

The only reason we don't realize this, is that it's not tracked and properly accounted for. If it were, and the costs associated with "bad" code were added to the acquisition costs of "bad" software, we'd all of a sudden see that "bad" code is lots more expensive.

Where's it easier to fix a problem...Design, and do it once, or after you have 5-10 or even 100 million copies running around? Sure, it takes a while, and it's not cheap to do at design time, but it makes a whole lot more sense! Not to mention that if the source is closed, only the vendor can fix it. So, either you get NO fix, or the vendor who should have fixed it in the first place, does so, and forces you to spend the resources to fix all your copies.

As I said above, civil liability would help. A jury decides if the vendor used due dilligence to produce the code. If not, the resources should be recoverable from the vendor.

Cheers!

Re:We need more disciplines like this

[Pussy Is Money]

No, they shouldn't be. Unless you are paying for the certifications, that is.

Re:We need more disciplines like this

[swagr]

Software development, on the whole, is not practiced as an engineering discipline. It needs to be.
Your blanket statement is incorrect. Anything on this earth could be designed better. Bridges, watches, popsicle sticks, etc. Common sense tells us that we have to make tradeoffs. Higher levels of security, redundancy and certainty require more time and money. I do agree that some software engineers should be certified and depending on the software, some companies should be accountable. But not all. Does it take a certified engineer to "ok" a doormat? Would you pay $1000 for a "certified" doormat?

Re:We need more disciplines like this

[GSloop]

How about a market based approach. Eliminate the protections software gets from civil liability.

The market would then respond to additional costs from suits that prevail and cost the vendor lots of money. Investors would be wary of investing in companies that didn't have rigorous design, testing, and production methods. Etc. etc. etc.

The jury would decide the merits of the case. Primarily, did the vendor use due dilligence in producing the software.

Now, for all the libertarians. You'll all yell that government shouldn't be involved...Well, fine, software copyright just went out the window too. Software vendors want it both ways. They want full government protection of IP and copyright. But they don't want the legal system to be involved when they make crappy software.

Take one, expect to take the other. This situation, it seems to me, to be the great fraud of the twenty-first century.

Cheers!

Re:We need more disciplines like this

[Pussy Is Money]

The problem is not that people don't design. The problem is that software depends on other software.

When you build a bridge you can be certain that the laws of gravity won't change. When you build software you cannot be sure that in ten years time you'll be using ASCII, or TCP/IP.

It doesn't matter how much time you spend designing upfront. Obviously it is better to have a good design than a bad design or no design at all, but the design which is impervious to change simply does not exist. If your code is being used you will always need to go back and change your it. In the process errors creep in, no matter what. It does not help to make the errors very expensive. That just makes the software very expensive, very late, and very restricted. With possibly less errors. Because that is the problem: how will you know? We don't know now -- how does increasing the price help?

Re:We need more disciplines like this

[FrostedChaos]

To get a good program (virtually bug-free and good security...realize that these are one and the same) the structure must be quite rigid. We can't all go off coding as we wish, and just throwing the design and QA portions together on the fly.

Oh, wow. It's another "structured programming guru." And like all the others, he knows nothing about programming.

Good programming is not accomplished by managers or business structures, useful as those are. Good programming is done by good programmers, using a language that allows them to express themselves elegantly.

In case you were wondering, programmers generally use the term "bugs" to refer to flaws in the implementation of a program, not flaws in the design of a program. For example, the fact that Mac OS 7 had no multi-user mode was not a security "bug"-- it was never designed with multi-user mode in mind. The fact that Windows 95 had memory leaks WAS a bug, because it represented an incorrect implementation of the design specification.

It is possibly for a program to be buggy, but secure. For example, an FTP server can be immune to exploits, but still have memory leaks and random crashes. It is also possible for a program to be free of bugs, but insecure. If your FTP server is rock-solid stable, but never asks anyone for a password, you are in this situation. If you think, "but nobody could be stupid enough to ignore security in their product design!"... well, like I said, you haven't been in this business long.

There are a lot of things programmers can do to improve security:

1) Don't use C for networking software. All at once, buffer overflows (as well as faulty pointer arithmatic) become a thing of the past. Unfortunately, there are very few languages that can replace C for systems-level and speed-critical software. But even if you do end up using C, DON'T use the C string functions.

2) Think about your design BEFORE you implement it. It doesn't matter who the CEO of the company is, or how many managers are on the Managerial Board, if the programmers can't think for themselves. For example, can you think of situations where having your email program automatically download and run .exe attachments would be a bad idea? Apparently the folks at microsoft-- or at least the ones making decisions-- can't.

In my opinion, the best programming teams are small, focused teams of individuals, who can work with little interference from management. Trying to squeeze software development into "top-heavy" business models has never worked very well (*cough*, IBM, *cough*, OS/2). And finally, before you convince yourself that you know how to manage programmers-- try programming.

Re:We need more disciplines like this

[Dr. Bent]

Yes, you don't need a civil engineering degree to design a dollhouse. But on any non-trivial software project, if you don't apply some good software engineering practices (OOP and UML come to mind), it's going to take you twice as long, cost twice as much, and have twice as many bugs.

The inherient problem in "methodless" software development is that there's no standard way of thinking about design. Engineering is all about formalizing the design process so that any other engineer can understand it. Give a blueprint for a bridge from one engineer to another and it will take him about a day to understand it all. Try doing that with any reasonably sized software system. Unless you've stuck to a strict design principle that both the devlopers understand, it'll take you months to sort out how the system works.

Re:We need more disciplines like this

[Pussy Is Money]

You're simply mistaken. Government agencies have long, long lists of requirements that need to be satisfied before they will purchase a particular piece of software. POSIX adherence comes to mind.

The problem is: these lists don't help. Vendors just put in the minimal effort required to satisfy the government's checklists, and you end up with an implementation that is for all purposes useless, except to pass the checklists and close the contract. This is what Microsoft did when they needed Windows NT to support POSIX. That the customer ends up with a severely braindamaged (but still compliant) product does not seem to matter.

Re:We need more disciplines like this

[GSloop]

It is possibly for a program to be buggy, but secure.

Only by luck. Bugs will eventually lead to security holes. That's like saying "You can have accidents in your car without injuring anyone..." and then using this logic to claim that accidents aren't that big of a deal for injuring people.

I'm sorry, but that's a stupid approach. I'm not a manager. I DO know how to program - in fact, my first programming language was C. I'm not too bad, though I know what I excell at and what I don't. I'm mostly a security and networking guru.

You can take pot-shots all you like. The fact is that a wild-west approach to design, programming and QA won't get the job done right. Heavy handed, totally inflexible management PHB's won't either. There's a middle approach that will work. But I dare say that most projects I've been on and worked with took the wild-west approach much more often than the heavy management approach.

So, if I were asked to put effort into fixing the problem in general, I would focus on fixing the wild-west approach before anything else.

Cheers!

Re:We need more disciplines like this

[GSloop]

Did I miss something here? I didn't ever say ANYTHING about government regulation!

The only portion of my post that mentioned government was that software vendors want government to protect their copyright, but not subject themselves to a civil court for negligence in creating that same software.

They want part of government, but not the other. If you want copyright protection, then expect to also stand trial in civil court and defend yourself for shoddy software.

Seems fair to me.

Cheers!

Re:We need more disciplines like this

[AnonymousNonCoward]

This would make software much more reliable and siginificantly reduce the maintence cost for users.

And no one would code for free or for fun.

So what if windows crashes, it's MS's fault, I'm not happy with it, I use linux, that goes for eveything software related, we're not forced to use it. We often have no choice to cross a bridge though, and if that "crashes", we're dead.

I'm sure the guy who wrote the software for Nana's respirator will be held accountable if it shoots out CO instead of O2.

To require certifaction and accountability is necessary when peoples lives are at risk, but if it's just because you don't want to reboot, well, I think it's pushing it.

Besides, bad software should == bad reputation, which is the case for most "aware" and computer-clueful people, the rest trust the hype and marketing team.

I'm not saying the computer illiterate are dumb, I'm just saying they shouldn't hop on the bandwagon so easily.

Anyway, I'm going off topic, but non mission (life) critical software IMHO shouldn't require 100% liability.

Re:We need more disciplines like this

[Dr. Bent]

The best way is just to get a bunch of developers who know that the wild-west approach is a bad idea. If they know going in that they have to have a cohesive and well thought-out design, you won't need the heavy hand of management to get a reliable, well-engineered system.

Re:We need more disciplines like this

[Dr. Bent]

Your right, software does change, that's why any software engineering methodology worth it's salt helps you design FOR change.

OOP is a perfect example. By mainaining low coupling through the entire system, you make it very easy to change and replace objects without introducing bugs. So software engineering not only reduces your inital cost, but also your maintainence cost over time.

Re:We need more disciplines like this

[GSloop]

Ok, I'll bite.

How many bugs do you know about that were caused by us not using ASCII or TCP? NONE!

If the OS is designed right, the ability of other programs to interact with your program is very limited. DLL hell? In my opinion, that's an instabiltiy that comes from a poor OS design. Now, when an application falls into DLL hell, it probably wouldn't be fair to hold the application vendor responsible, but it sure as hell would be fair to at least see if MS could find adequate reasons for their approach.

A good design approach helps keep the landscape stable. Most programs are around for such short periods anyway, that the arguments you present are hardly issues at all.

If you think they are, how about using some realistic examples, rather than ASCII or TCP.

Cheers!

Re:We need more disciplines like this

[GSloop]

That helps, but I personally don't think it's enough. It depends on the scope of the project and many other factors, but certainly on mid-size to larger projects, I think a more structured approach would yield better results.

Cheers!

Re:We need more disciplines like this

[Anonymous Coward]

to call oop software engineering is ignorant at best, insulting to engineering as a general discipline at worst.

Re:We need more disciplines like this

[imadork]

How about a market based approach. Eliminate the protections software gets from civil liability.
Software vendors want it both ways. They want full government protection of IP and copyright. But they don't want the legal system to be involved when they make crappy software.

There's are basic problems with the Market Based approach which make it unusable -- Since there are so many distinct parts of software (OS Kernel, OS Services, Applications, Libraries, Device Drivers) that may be made by different vendors, how can you pin the blame for a software problem on a particular vendor if you're not 100% sure where the problem is? Or what if the code from two vendors is technically correct in isolation, but creates a security problem when used together? Who gets sued then?

I'm not sure of there's a practical way to enforce civil liability for software products unless the acual code is examined in the trial. Which eliminates the whole concept of Proprietary software. Most /.ers would welcome that, but I guarantee their employers won't.

And given that these trials are decided by twelve people who couldn't get out of Jury Duty, how will they possibly be able to understand the technical merits of such a case? They'll probably be swayed by the lawyers in the better suits, which will belong to the big software companies. Or the class-action law firm that sues the small companies under this statute.

In short, eliminating civil liability protection for software will insure that only big companies that can afford to go to trial with the class-action lawyers will be able to write software. Forget about small companies. And forget about cooperative Open-Source development -- that just gives Class-action lawyers more people to sue.

Re:We need more disciplines like this

[Pussy Is Money]

You are missing the point. Algorithms that work for ASCII will not work (and at the very least, are not certified to work) with Unicode. Programs that depend on IPv4 may not work (and at the very least, are not certified to work) with IPv6. And the notion that "most programs are around for such short periods anyway" is what brought us Y2K.

Re:We need more disciplines like this

[CaptainSulu]

Interestingly enough, the "certifications" that are currently out there, like MCSE, are prohibitively expensive and are meant to be eye candy on your C.V. rather than make you accountable for your software.

An engineering discipline also entails a systematic approach to solving problems and a way of codifying best practises; I think software engineering does both of these things. Perhaps not as well as they could be done, but good attempts are being made.

Re:We need more disciplines like this

[Anonymous Coward]

History repeats itself.
Check out http://www.iccp.org/ - I was the only one of a group of six to pass the CCP back in 1981. The intent then was to avoid being government certified by being self-certified.

Re:We need more disciplines like this

[Pussy Is Money]

You talk as if all these problems have been solved. But they haven't. You cannot just say "software engineering methodology" and "design for change" and get something that works. Because the goal is not so much to "design for change" or to "make it very easy to change and replace objects": the goal is to deliver correct, efficient code within budget and on time. A software engineering methodology is only "worth it's (sic) salt" in so far as it helps you achieve that goal. And as much as I hate to be the one to have to bring it to you, "making it very easy to change and replace objects" might be a lot of fun, and it sure sounds expensive, but it is not by itself conducive towards the goal.

OOP might make it twice as easy to maintain your code (whatever that means), but that is not necessarily a benefit if it means your code has to anticipate four times as many calling contexts, and you have to consider sixteen times as many code paths -- both (although a bit exaggerated perhaps) natural results of the code reuse that you get with OOP. That's not to say that OOP does not have its use: of course it does. But you are making a trade-off, and although current fashions dictate that the trade-off is always worth it: this is just not so. It may be, or it may not be. Sometimes designing for change is necessary, but sometimes not. Sometimes OOP is nice, but sometimes not. It comes down to the fact that you don't design "for change", but for the customer. Granted, there are aesthetics involved. OOP captures some of these very nicely. But when you focus on the problem, and not the "methodology", you find that these and other aesthetics exist in every other language and every other methodology as well: from C to Scheme, from bash to VBScript, from the quick hack to the deep thought.

There is a lot of merit in a more managerial (because that is what most of the "software methodologies are: they have very little to do with engineering) approach to software development. Management requires measurement, and without procedure it becomes impossible to measure. So, software developers need to follow procedures, adopt a certain style of programming and adhere to standards. Otherwise it becomes impossible to measure progress. But you have to be careful not to confuse the measurements with the actual goal: just because the project follows a "design methodology" doesn't mean that the customer has to like the end result.

Re:We need more disciplines like this

[CaptainSulu]

I think there is considerably more literature and research going into software engineering than 12th century medicine.

A few examples:

http://sdg.lcs.mit.edu
http://research.microsof t.com/foundations
http://hillside.net/patterns/
http://xprogramming.com

Although you bring up a valid point that many new programmers still treat it as a dark art shrouded in mysticism. Random debugging, not using source control, etc. I guess this is where certification would be useful, but as a badge of pride or mark of excellence (like a TopCoder ranking) rather than a shock collar to electrocute you when things go wrong.

Re:We need more disciplines like this

[Pussy Is Money]

This is what you wrote:

Investors would be wary of investing in companies that didn't have rigorous design, testing, and production methods. Etc. etc. etc.

In other words, you want software to confirm to a wide range of standards. A checklist so to speak. The example I gave you shows you how these ideas turn out in reality. The government requires POSIX? Microsoft writes you the most miserable POSIX implementation around. Problem solved!

No, not really. Problem not solved. See my point?

Re:We need more disciplines like this

[Dr. Bent]

You're missing the point.

It's not the FUNCTIONALITY we want to conform to a standard it's the DESIGN METHODOLOGY. There's a big difference.

You can write any application you want using OOP. It doesn't limit your functionality at all. You can use the POSIX standard, or an M$ standard, or the standard from BillyBob's house of code...

Engineering is using a standard methodology to solve general problems. If the problem set the methodology can solve isn't totally general, then the methodology is useless.

Re:We need more disciplines like this

[Pussy Is Money]

Well, okay, you're with the Church of OOP and DESIGN METHODOLOGY. That is wonderful. I suppose that by obscuring the workings of your program (by encapsulating stuff inside, say, an object), it becomes possible to maintain code without having to understand what it does. That's good. The problem is that it leads to people maintaining code without understanding what it does. And that's bad. What any of this has to do with engineering I'm not sure.

Re:We need more disciplines like this

[Dr. Bent]

You're wrong is so many places I'm just going to make a list.

Software engineering methodologies in general (and OOP in particular):

- Are always worthwhile for non-trivial systems because their overhead is linear (as a function of system size) while software errors and complexity are exponential.

- Require no additional work to add modularity (the ability to replace or change components). It is a natural function of following the methodology.

- Require no managerial oversight unless the programmer does not understand the methodology (which is standardized, so he can learn it from a book)

- Reduce QA time by allowing for unit testing and pre-QA'd components.

- Reduce program complexity by replacing complex procedural code with simple polymorphic objects. The net result is less lines of code, less code paths, but the same functionality.

- Can increase system performance through efficent design. (The fastest code is the code not executed)

- Do not guarantee program correctness, but do reduct the cost (a.k.a Time) to achieve it if used properly.

And I have 5 years of Object-Oriented development experience to back up these claims. Given your posts I doubt you even really undertand OOP.

Re:We need more disciplines like this

[cduffy]

There's are basic problems with the Market Based approach which make it unusable -- Since there are so many distinct parts of software (OS Kernel, OS Services, Applications, Libraries, Device Drivers) that may be made by different vendors, how can you pin the blame for a software problem on a particular vendor if you're not 100% sure where the problem is?

Isolating bugs isn't that hard -- while there are a number of different layers, they each do different things; find out in doing what the failure occurs, and then you know the layer. But then maybe I'm speaking from the wrong viewpoint -- I've been working (and playing) with OSS for the last seven years (jeesh, it doesn't seem like that many!) and I've not yet seen a bug that, given enough time, can't be tracked down to its source.

Or what if the code from two vendors is technically correct in isolation, but creates a security problem when used together? Who gets sued then?

Whoever you hired to do systems integration, of course.

I'm not sure of there's a practical way to enforce civil liability for software products unless the acual code is examined in the trial. Which eliminates the whole concept of Proprietary software. Most /.ers would welcome that, but I guarantee their employers won't.

Ya know, it's not unheard of for evidence of a proprietary nature (trade secrets and such) to be sealed or otherwise withheld from the public record. Further, my employer wouldn't mind -- the source we work with is already public.

And given that these trials are decided by twelve people who couldn't get out of Jury Duty, how will they possibly be able to understand the technical merits of such a case? They'll probably be swayed by the lawyers in the better suits, which will belong to the big software companies. Or the class-action law firm that sues the small companies under this statute.

What do you think expert witnesses are for? Alternately, if need be, the court can appoint their own experts. As for the class-actions, lawsuits don't just happen -- someone has to at least think they've been wronged, and convince a lawyer that they really have been wronged (presuming said lawyer is working on a contingency fee, there's quite a motivation to be sure you only take cases you really can win).

In short, eliminating civil liability protection for software will insure that only big companies that can afford to go to trial with the class-action lawyers will be able to write software.

You mean big companies with deep pocketbooks will be the only ones able to write bad software.

Forget about small companies. And forget about cooperative Open-Source development -- that just gives Class-action lawyers more people to sue.

I agree that folks giving away a product at zero cost should be able to disclaim even implied warranties -- that's not so hard a thing to put into law. Heck, I take the position that anyone should be able to disclaim warranties -- as long as the customer is very, very aware of it before the purchase. Symantec wants to sell an undertested release of SystemWorks and be immune from lawsuits from folks who lose data? Fine -- but they put their notice on the outside of the box, in bold letters. Then I'll be happy.

Re:We need more disciplines like this

[cduffy]

First off, I like OOP -- a lot. I'm presently maintaining a legacy system with a ridiculous amount of spaghetti code, and in doing so have realized how much I miss the modularity and clarity that comes with code designed using modern techniques. That said, I'm not entirely sure I agree with all your points.

Require no additional work to add modularity (the ability to replace or change components). It is a natural function of following the methodology.

And following the methodology has no overhead?

Looking at it from a different perspective, there's still work involved in being able to swap components out at runtime without source changes; indeed, writing a simple plugin architecture is frequently easier in C than C++ (though admittedly any true OO language -- such as Java or Python -- trumps them both).

Can increase system performance through efficent design.

Rarely to never have I seen software with a decent OO design have less unnecessary code rather than more. For components to be generalized (which is certainly a good thing!) there's overhead; for initialization of an object with several superclasses there's overhead; heck -- the average call stack length one has to deal with while debugging OO code bears me out on this one. OO methodologies can result in reduced development and debugging time if used correctly, but increased runtime efficiency is something with regard to which I'm completely unconvinced.

Re:We need more disciplines like this

[Anonymous Coward]

Perhaps something that COULD easily be changed: ie teach software engineering in school. Many schools don't teach it. They assume its something learned on your own. Nothing makes up for experience, but there are certainly some general things that may be taught to equip newly graduated software engineers.

Re:We need more disciplines like this

[Dr. Bent]

And following the methodology has no overhead?
What I'm saying is that if you follow the methodology, you get all the benfits (like modularity) without having to always concentrate on how to achieve them...they almost happen naturally. Yes, there's an overhead involved, but you get way more than you put in.
Rarely to never have I seen software with a decent OO design have less unnecessary code rather than more..
You're right about the call stack length, however good OO design fosters (almost forces) the designer to think long and hard about the problem space. The result is an OO design that more closely models the problem than a procedural design. And the smaller the 'distance' between your model and the actual problem, the more efficent your design. (Again, the fastest code is the code not executed). Basically, you trade some raw performance for logic optimizations, and as any computer scientist knows, a better algorithm beats raw computing power any day of the week.

Re:We need more disciplines like this

[GSloop]

All I can say, is

CAN I HAVE SOME OF WHAT YOU'VE BEEN SMOKING?

You're so out of touch with reality, it scares me.

That, or your reading comprehention SUCKS!

[Flame mode off]

Cheers!

Re:We need more disciplines like this

[cduffy]

The result is an OO design that more closely models the problem than a procedural design.

Maybe if you compare good OO design to bad procedural design -- but comparing good OO design to good procedural design (or even just average work of both varieties), that Just Ain't So. Indeed, not infrequently folks of average skill doing OO code tend to just pick a class with the correct interface for what they want to do without thinking about what's going on under the hood, and so end up (for instance) choosing a list where a hash would be more appropriate, or using access methods which are inordinately slow (but which were provided for compliance with some interface). Does this ever happen when someone competant is doing design? Of course not. But competant folks doing procedural design are at least as effective.

I entirely agree that a better algorithm trumps smaller optimizations -- I've written Python code with a good algorithm hundreds of times faster than a naiive C implementation intended to do the same thing. HOWEVER, there's nothing innately OO about good algorithmic design. Maybe you can only design good algorithms when working with OO, but don't assume that OO and good algorithmic design are inherintly linked; simply put, they aren't. Well-done OO design makes for more maintainable, reusable and modular code -- but better logic or faster runtime performance? Simply put, you still leave me unconvinced. Indeed, designing a large program procedurally is almost certainly far harder than doing it via OO; that it's possible to design a large program procedurally without "think[ing] long and hard about the problem space" is an assertion I simply don't accept.

Re:We need more disciplines like this

[FrostedChaos]

Nothing will substitute for good programmers and a good design. If you have some other "secret recipe," then please tell us what it is. And you can turn off the +1 posting bonus for this-- I can read your comments just fine.

Sample Chapters

[Akatosh]

Here you can find a pdf off chapter 10, chapter 18, and chapter 1.

Re:Sample Chapters

[Anonymous Coward]

The book is simply brilliant. I have been working in security (professionally) for almost 7 years, have read many number of books and huge number of papers, but nothing compares to this one. Incredible breadth and deep insight.

If you haven't got money to buy book or access to a library, have a look at Ross's website, there are many of his papers on which the book is based.

http://www.cl.cam.ac.uk/users/rja14/

jl

Monitoring

[yintercept]

I threw this book in my to read list. BTW, I've found that people are probably a more important part of your security strategy than just code. Every program I write begins with a security mechanism that drops any anomolies into a database. Severe problems get emailed to an admin or activates their pager. The program does a great job detecting and reporting security breaches, but means squat if no one ever acts on the problems or turns off their pagers. It generally is an uphill battle to get a company to train resources in monitoring their systems, and to give adequate rewards to the admin who gets woken up at 3AM because some one is trying to hack a password in the system.

Here are some extracts...

[Cyberdyne]

One point the reviewer missed is that Ross put a few chapters of the book on his home page here. There's a page about the book itself here with links to a couple of chapters.

From what I've seen of it so far, it's a good book (Disclaimer: yes, he was my project supervisor last year!). A few funny typos etc in the errata, which is well worth a look, too, especially anyone wondering who the hell this "Prince Schneier" guy on p 113 is ;-)

Why even bother reading the review?

[x1l]

When someone starts off by saying
"I thought I would do a review on one of my favorite books."

I guess this is objective, since it is one of his favorites.

Re:The Language of God

[atcroft]

Sounds like a good book. As someone with a system dropped into his lap which was never designed to be distributed (but now is), the review interested me, and I'm likely to soon try to obtain the book (or at least look at it).

One problem I often faced by developers is not so much that they don't want to write good secure code, but they are under such deadlines that they can't take a break to learn how. For some, their early training may not have included the idea of the application being distributed, or prepared them for the issues inherent in such environments. The other issue I tend to see is users during testing clamoring that the security that may have been put is unnecessary, or slows down the process, or it is too much to remember, or... *bang head against nearest hard surface, repeat*

In response to your sig (and slightly off-topic to the article), an off-shoot of the Cygwin project (housed at http://sources.redhat.com/ ), includes an implementation (under "More projects") of XFree86 using the Cygwin API to run under Windows 9x/NT/2k/XP.

Book is a LOT (40%) cheaper at Amazon!

[SuperKendall]

I know it's all the rage to hate Amazon. As for myself, I think the annoyance of things like one-click patent support do not quite outway the good Amazon has done or the fact they have a well-built site that I enjoy more than almost any other.

I do buy books from FatBrain from time to time, and even wear a FatBrain baseball hat they were kind enough to send me some time ago. But when a book is $60 at FatBrain, and $36 at Amazon... well, I like donating money to the EFF but I'm not sure I am quite THAT supportive of FatBrain. So if you're on a limited budget, you might want to order the book here instead (and no, I don't get anything from the link - go to Amazon yourself if you are paranoid).

Just for completeness, it's $51.95 at Bookpool.

Re:Book is a LOT (40%) cheaper at Amazon!

[LarryRiedel]

It is priced comparably to Amazon at BooksAMillion.

"Best Web Buys" provides price comparisons for books and music.

Re:Book is a LOT (40%) cheaper at Amazon!

[Wakkow]

Listing of prices at addall.com

For true completeness.

Purchasing _Security Engineering_

[MadSaxon]

Just FYI, this book is $60.00 at Fatbrain but
$36.00 at Amazon. I like Fatbrain and all,
but $24 is $24...

Read it before the UK government makes it illegal

[armb]

Yes, you thought dumb crypto laws were a thing of the past, but no, here comes the UK trying to copy what the USA already gave up, only without that tedious constitutional protection of free speech stuff.

http://www.cl.cam.ac.uk/~rja14/exportbill.html
(yes, rja14 is the Ross Anderson who wrote this book).

Also

[wiredog]

"Database Nation" from O'Reilly

On Software Development as Engineering

[essiescreet]

This is valid, to a point, here's where it falls apart: You want to build a bridge: 1. Draw Plans 2. Have plans approved by inspector 3. Dig and pour foundation 4. Have foundation approved by inspector 5. Put up pylons, supports, whatever 6. Have them approved by inspector 7. Put the horizontal top on the bridge 8. Have top approved by inspector 9. Pave road 10. Have pavement approved by inspector 11. Bridge gets reviewed every year by inspector to check for flaws, maintainence needs, etc. Now, not all these apply to software development, but I hope you can see some parallels. Also, There is not much innovation in this type of method. You know your load, materials (and their thresholds), traffic load, weather, and most other variables, and you can use a mathematical formula to solve them. Show me this for software development! Now, certifing developers is a good idea, as is holding people accountable for their mistakes, but treating software developers like you would civil/mech/areo engineers is a farce, and is only purported to work by people who heard it in school and are just spouting it back out.

Re:On Software Development as Engineering

[bmckinle]

It would help for everyone to read some history
(humans don't live long enough) regarding the
evolution of engineering disciplines from
their respective sciences. Software Engineering
is just that. Computer Science lacks many of the
formalisms to properly discipline the engineering
that results. And that is all there is to it.
This does diminish software engineering as a proper
discipline, however. If you have been building
systems as long as I have (20+ years) and you have an engineering degree at least (and you have an open mind), then you have ground to talk on. Otherwise, you are arguing with yourself to no
end.

My opinion, in short, is that if you think that
all there is to software engineering is just
code, then I'll tell you what I tell the "coders"
in my lab that keep repeating the same engineering
mistakes: you don't understand the problem space
and that's why your "code" does not work. Understand the problem (a science) and the code solution will present itself.

By the way, the "coders" work for me, not the
other way around.

Re:On Software Development as Engineering

[Anonymous Coward]

I am in awe at how incorrect you are for someone who's been a system engineer as long as you have.

Computer science has a full and complete theoretical underpinning of computation. I won't go into the models used as you've probably never heard of them or done any proofs with them.

The issue is that of complexity and the fact the formal techniques don't scale. Software is more flexible and complex than virtually any other type of construction material. To formally verify that any system of substantial size implements its specification is computationally impossible. Specifications are typically far too complex to verify that they themselves are correct.

The other issue is cost. Better designs could be done, use of more formal techniques could be applied at all levels in sofware engineering and better software could be written but there is a tradeoff with time and cost. Most home users aren't willing to spend $35,000 for a copy of Word (a *remarkably* complex piece of software).

Re:On Software Development as Engineering

[cdegroot]

Two remarks on this:

1. At least engineers make time to do drawings, documentation and inspections. If software people would be qualified engineers, they'd ask for that time as well.
2. A bridge engineer is responsible enough not to use the equivalent of sprintf() and other buffer-overflow-inducing things (in fact, he'd probably not use C but some safer language).

Both of these would arguably slow down software development, cut back heavily on features (and on feature bloat), and would improve quality and security. When society finds the latter more important than the former, we'll see licensed software engineers.

do NOT use the link provided to buy this book.

[einer]

60.00 from fatbrain?!Go to bestbookbuys.com (a comparison shopping site much like pricegrabber) and pick it up for under $40.00

Re:do NOT use the link provided to buy this book.

[einer]

(Yes, I'm that guy... The one that replies to his own post... )

here is a link for the book for $36.00 shipped.

Note to new slashdotters: Slashdot puts spaces in the links, so just 'right click' and 'copy link location' then paste it in your URL bar and remove any spaces.

How?

[JMZero]

How do you detect intrusion? Of course you can do things like the following (in a login based web app):

1. Watching for too many password tries
2. Watching for too many page views/write attempts by a particular user - logging things
3. Blocking and logging long queries/odd characters/queries with errors

What else can I do? I try to write clean, secure code - but I don't know what the big threats are around the corner.

Should I be working harder to avoid cross-site scripting issues on pages past the login page? What's the odds of it being exploited? I use a session key, should I be changing it on every page view? Should I tie session keys to request IP (I do now), or is that pointless? Should I be extending my SSL key length?

And while I think about this, I notice some user has their password on a little sticky note on their monitor.

There's so many security threats to worry about. Does anyone have a resource that might suggest which are the first ones I should point my time at? Or a list of security failures and how they happened?

.

Re:How?

[OblongPlatypus]

A question for you... how do you get by tying session keys to request IP? I'd love to do that for my web app, and I think it's far from pointless (IP spoofing is beyond the level of the sort of person who would try to hack my system), but I'm stumped by the fact that some ISPs (including AOL) will give its users different IPs from one request to the other. How do you handle that? Or doesn't your app have AOL-using users?

Re:Speaking of security...

[Anonymous Coward]

Doesn't one of the speeches violate the DMCA?
Watch out for the thought police!

USA vs. other countries

[OblongPlatypus]

I have little to no knowledge about how the whole engineer certification thing works in the states, but I thought I'd share my situation anyway. If anyone would like to enlighten me about how it works in the states in a reply, I'd be most grateful.

I live in Norway, and I'm currently three quarters through the first year of a 5-year study to become a civil engineer in "computer technology". Although it may not sound like it, this study branches into eight different subjects, most of which are entirely software oriented. In four years, I'll graduate as a civil software engineer, every bit as much of an engineer as an engineer of electronics or other traditional engineering sciences. There are similar degrees in such diverse subjects as chemistry, industrial economics and technology management, mathematics, and communication technology.

Programming security humm...

[shadoweye]

What programming languages are considered secure for you? I've been told Java is secure but how about C and C++. This is a very important topic for those in the developing community.

Re:Programming security humm...

[Anonymous Coward]

Languages aren't necesarrily secure or insecure by themselves. It is much more important to be aware of security pitfalls in a given language, and use it properly.

That said, Java programs are not going to have some of the attacks, such as buffer overflows, that plague C and C++. Using C or C++ just requires more caution during implmentation to do securely.

A secure design is most important. If you have a broken design, a bulletproof implementation is not going to help a lot.

From the diary of an American anarchist

[October_30th]

We want to destroy all states, and all churches, with their institutions and their laws of religion, politics, jurisprudence, finance, police, universities, economics and society, in order that all these millions of poor, deceived, enslaved, tormented, expolited human beings, delivered from all their official and officious directors and benefactors, associations and individuals, can at last breathe with complete freedom.

We are the natural enemies of those who dream already of the creation of new revolutionary states.

Just read it

[the_rev_matt]

I just finished reading it, and it is mandatory reading if you are developing security these days. It covers a very broad range of situations and assumes a fair amount of familiarity with the math behind crypto, so this isn't "Teach Yourself Security in 24 Hours for Dummies".

Re:Tying session key to IP

[JMZero]

Occasionally someone's IP will change, especially if they're logging in from home. If it does, we force them enter their login again (and we have a mechanism to preserve their last work).

This would, of course, get mighty tiresome if your IP changed after every request - so far it hasn't come up.

Like you say, IP spoofing does add another burden to the hacker. But is it that much of a burden to a hacker who's already managed to obtain a session key? Who knows.

We've avoided using client certificates because they're onerous to administer - but we may end up doing that soon. Security is a tough game for me - I know some of the moves, but I don't know who my opponent is and I can't see his pieces.

.

cool

[Anonymous Coward]

sounds great! can someone please post a link where i can download this book? obviously i wouldn't dream of buying it, as it is the fruits of someone's intellect and therefore implicitly my property.

even better if is it available on some l33t network like freenet, that would be k-rad.

thanks for your help.

Re:cool

[anonymous_wombat]

This is the first actually funny post that I have seen on /. in quite some time. How is it modd'ed to 0?

Sorry, but...

[Anonymous Coward]

It would also mean that a software project would take over fifteen years to finish. Are you willing to wait that long?

You can't have rigorous engineering and ridiculously fast development and all the good stuff with understaffed offices. It just doesn't work like that.

Developers and security? Pffft...

[technopinion]

I recently worked on contract at a *major* bank doing web (intranet) programming in one of their IT departments. There were about two dozen people in this department, working on everything from banking apps to back-end HR systems, and *none* of them really had a clue when it came to security.

We had people embedding SQL userid/passwords in client-side javascript, passing stuff in plain text in query strings that should have been SSL'd, and other fun stuff. I tried to hit a few of these people with a clueX4, but most just couldn't be bothered learning even the basics of security standards. It was pretty scary.

All developers should be forced to take a few security courses before they even get to touch a computer in the workplace, and even then, audit audit audit...

Some more recommendations

[Michael Schuerig]

I'm no security expert, I've only just recently started reading. And incidentally, a couple of days ago I've begun reading "Security Engineering". So far I share the reviewers very good impression.

I'd like to recommend some complementary books; each of these approach security from a different angle

• Secrets & Lies by Bruce Schneier. Deals with the "soft" issues. What are the threads to networked systems? Who are the attackers? One of the messages: Risks can't be avoided -- manage them.
• Building Secure Software by John Viega and Gary McGraw This one's closer to technological issues related to security. Risks of various base technologies (languages, middleware). Introductory details on buffer overflow attacks, random numbers, cryptography. Some organizational/dev process stuff.
• Secure Programming for Linux and Unix HOWTO
• by David A. Wheeler. Technical security down to the C-level. Programming techniques.

Michael

Err, let me wiesel out of part of that...

[cduffy]

But competant folks doing procedural design are at least as effective.

Let me clarify my words here. Competant folks doing procedural design tend to choose and use algorithms which result in runtime performance at least as good as those selected by folks doing OO. I don't mean to imply that folks doing procedural design can do better than OO design in terms of time to complete or debug the product -- indeed, I consider OO a superior methodology in most cases, certainly including almost all large projects. On the other hand, fairly small amounts of code which need to be written for optimal runtime performance (I can think of quite a few libraries that fall into this category; kernelspace code fits as well) are better off being designed and written procedurally.

Btw, I'd prefer it if you'd reply to the parent post rather than this -- it's intended merely as a clarification, rather than a post capable of standing on its own.