Security Engineering 112
| 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 ContentsPart One
- What Is Security Engineering
- Protocols
- Passwords
- Access Control
- Cryptography
- Distributed Systems
Part Two
- Multilevel Security
- Multilateral Security
- Banking and Bookkeeping
- Monitoring Systems
- Nuclear Command and Control
- Security Printing and Seals
- Biometrics
- Physical Tamper Resistance
- Emission Security
- Electronic and Information Warfare
- Telecom System Security
- Network Attack and Defense
- Protecting E-Commerce Systems
- Copyright and Privacy Protection
Part Three
- E-Policy
- Management Issues
- System Evaluation and Assurance
- 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.
Re:The Language of God (Score:2, Insightful)
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.
Speaking of security... (Score:3, Informative)
Sugaring the pill (Score:3, Insightful)
Any books w/sample code? (Score:1)
If one was looking for a book with samples of writing secure code, does anyone have any recommendations?
Re:Any books w/sample code? (Score:1)
http://www.openbsd.org/slides/musess_2002/index.ht ml [openbsd.org]
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? (Score:3, Informative)
I heartily recommend the book Building Secure Software (How to Avoid Security Problems the Right Way) [buildingse...ftware.com].
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 [sourceforge.net] 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? (Score:2)
A good example is: http://www.atstake.com/research/reports/wprasbuf.
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!
Re:Any books w/sample code? (Score:2)
Re:Any books w/sample code? (Score:1)
Secrets and Lies (Score:5, Informative)
Also (Score:2)
Secret Lies by Bruce Schneier (Score:2, Interesting)
We need more disciplines like this (Score:3, Interesting)
This would make software much more reliable and siginificantly reduce the maintence cost for users.
Re:We need more disciplines like this (Score:3, Interesting)
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 (Score:2, Informative)
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
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 (Score:2)
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 (Score:1)
Re:We need more disciplines like this (Score:2)
Cheers!
Re:We need more disciplines like this (Score:1)
Re:We need more disciplines like this (Score:1)
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 (Score:2)
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 (Score:1)
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 (Score:1)
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 (Score:1)
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 (Score:1)
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 (Score:1)
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 (Score:1)
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 (Score:1)
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.
Err, let me wiesel out of part of that... (Score:1)
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.
Re:We need more disciplines like this (Score:2)
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 (Score:1)
Re:We need more disciplines like this (Score:2)
Re:We need more disciplines like this (Score:1)
A few examples:
http://sdg.lcs.mit.edu
http://research.microso
http://hillside.net/patterns/
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 (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:1)
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 (Score:2)
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 (Score:1)
No, not really. Problem not solved. See my point?
Re:We need more disciplines like this (Score:1)
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 (Score:1)
Re:We need more disciplines like this (Score:2)
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 (Score:2)
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 (Score:1)
Re:We need more disciplines like this (Score:1)
Re:We need more disciplines like this (Score:1, Flamebait)
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 (Score:1)
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.
USA vs. other countries (Score:4, Interesting)
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.
Re:We need more disciplines like this (Score:1)
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.
Sample Chapters (Score:4, Informative)
Re:Sample Chapters (Score:1, Informative)
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 (Score:3, Insightful)
How? (Score:2)
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? (Score:2)
Re:Tying session key to IP (Score:1)
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.
.
Here are some extracts... (Score:4, Informative)
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 [cam.ac.uk], 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? (Score:1, Insightful)
"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.
Book is a LOT (40%) cheaper at Amazon! (Score:4, Informative)
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 [amazon.com] 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! (Score:1)
"Best Web Buys" [bestwebbuys.com] provides price comparisons for books and music.
Re:Book is a LOT (40%) cheaper at Amazon! (Score:1)
For true completeness.
Purchasing _Security Engineering_ (Score:1)
$36.00 at Amazon. I like Fatbrain and all,
but $24 is $24...
Read it before the UK government makes it illegal (Score:2)
http://www.cl.cam.ac.uk/~rja14/exportbill.html
On Software Development as Engineering (Score:3, Insightful)
Re:On Software Development as Engineering (Score:1)
(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 (Score: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.
- 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. (Score:2, Informative)
Re:do NOT use the link provided to buy this book. (Score:1)
here [bestwebbuys.com] 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.
Programming security humm... (Score:1)
Just read it (Score:2)
Re:cool (Score:1)
Developers and security? Pffft... (Score:1)
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 (Score:2, Informative)
I'd like to recommend some complementary books; each of these approach security from a different angle
Michael