Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Image

Security Strategy: From Requirements To Reality 64

brothke writes "Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson is arguably the best information security book ever written. Anderson's premise is that security technology needs to take a structured engineering approach to systems design, with detailed requirements and specification from start-up to development and implementation; just as those designing buildings and bridges do. Without a deeply embedded structured approach to security systems design, Anderson argued that we find ourselves in the situation we are in today, with applications and operating systems full of bugs, vulnerabilities and other serious security flaws. As good as Security Engineering is, it was not written to be a detailed information security design guide. That vacuum has been filled by an incredibly important and valuable new bookSecurity Strategy: From Requirements to Reality." Read on for the rest of Ben's review.
Security Strategy: From Requirements to Reality
author Bill Stackpole and Eric Oksendahl
pages 346
publisher Auerbach Publications
rating 10/10
reviewer Ben Rothke
ISBN 1439827338
summary One of the best information security books of the last few years
Security Strategy is one of the first books that shows how to perform a comprehensive information security assessment and design, from section, development and deployment of a security strategy best suited to a specific organization.

The books main focus is on the planning, requirements and execution need to ensure formal and comprehensive information security elements are built into systems, applications and processes.

Authors Bill Stackpole and Eric Oksendahl each have over 25 years in the industry and the book reflects their vast expertise. Oksendahl spent time at Boeing, one of the most security aware organizations, with Stackpole spending a decade at Microsoft. While Microsoft is chided for creating more insecurity than security, it is worth noting that no organization in the world has spent more on training its staff and developers on security than Microsoft.

The books 300 densely written pages are composed of 14 chapters divided into 2 sections. Section one (chapters 1-6) is about strategy, with section two (chapters 7-14) around tactics.

Complete with checklists of the physical security requirements that organizations should consider when evaluating or designing facilities, the book provides the insight needed to enable an organization to achieve the operational efficiencies, cost reductions, and brand enhancements that are possible when an effective security strategy is put into action.

Chapters 1-3 take a high-level overview on how to approach strategy, with its many details. The authors note that strategy is a long-term plan of action designed to achieve a goal that includes what work will be done and by whom. This is not a trivial task, as many organizations simply roll-out a new technology, without defining what its goals are, and who exactly will manage and support this new technology.

Chapter 4 is where the hard work begins, as this chapter details the issues around strategic planning. Noting that strategic security planning is hard work and takes time; many organizations attempt to take an assumed easier path, that of bypassing security details and specifications. That is precisely why information security is in such a sorry state in many firms. These firms would rather buy a security appliance and place it in their data center and hope it works; rather than defining the details and specifications of what the appropriate appliance is in the first place.

Part 2 commences on the topic of tactics, and defines them as procedures or sets of actions used to achieve a specific objective. What this chapter does well, as does the entire book, is that it compels the reader to focus on specifics and objectives.

Chapter 9 gets into the importance of observation, in knowing what is going on within the network. The book notes that observation is both a deterrent and a detector. The chapter goes into detail about how observation works both in the physical world and its corollary use in the network side. The chapter breaks down the various functions needed to ensure that observation is done correctly; as opposed to the common method of simply rolling out an IDS and hoping that it somehow works.

Chapter 11 details the SDL (security development lifecycle). As the chapter notes, an effective SDL can improve application security via the use of a set of development practices designed to reduce or eliminate exploitable vulnerabilities. The issue though is that far too few organizations realize the need for a SDL, let alone take the time to design and deploy it.

Chapter 14 ends on the topic of security awareness training. While the notion of security awareness for many firms is an annual 10-slide PowerPoint; the authors take a pragmatic approach and detail the various parts of what makes for an effective awareness program.

Security Strategy: From Requirements to Reality is an incredibly valuable book that advances the state of information security. For organizations that are looking to get serious about information security, and those that want to go from good to great, the book is an invaluable guide that lays the groundwork on how to develop a first-rate information security infrastructure.

Taking a look at its table of contents shows the many fine points in which the book goes into each particular point, showing how it can be properly designed and deployed for effective security controls.

My only peeve with the book is that it lacked a CD-ROM or web site in which to download the many tables and matrices the book is built on. It is hoped that future editions will have them available.

Security Strategy: From Requirements to Reality is one of the best information security books of the last few years. Those who are serious about information security will ensure this is on their reading list, and that of everyone in their organization tasked with information security.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase Security Strategy: From Requirements to Reality from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

*

This discussion has been archived. No new comments can be posted.

Security Strategy: From Requirements To Reality

Comments Filter:
  • tl;dnr (Score:2, Funny)

    by falldeaf ( 968657 )
    This book seems like a whole lot of work... isn't there a lazier approach that would just make my servers *feel* more secure?! Ostriches have the right idea, I think. ( P.S. After this post, I hope my IP isn't viewable by the public... )
    • Your servers need a blanket.

      Oh, you thought I meant THAT Linus...

      • A security blanket... brilliant. As long as it holds up under the immense heat from restricted airflow, I have feeling my fears are over! Oh wait though, didn't Ben Franklin have something to say about this? Like, "Those that would accept restricted airflow in exchange for false security deserve to have all their components reflowed in their makeshift towel oven", I think.
  • by Daffy Duck ( 17350 ) on Monday November 15, 2010 @02:59PM (#34234782) Homepage

    While Microsoft is chided for creating more insecurity than security, it is worth noting that no organization in the world has spent more on training its staff and developers on security than Microsoft.

    Is it worth noting that? To me, that just reads as "Microsoft is a very big company".

    It could well be the case that no organization in the world has spent more on cheese than the U.S. government. That wouldn't make me want to eat it.

    • by BobMcD ( 601576 )

      While Microsoft is chided for creating more insecurity than security, it is worth noting that no organization in the world has spent more on training its staff and developers on security than Microsoft.

      Is it worth noting that? To me, that just reads as "Microsoft is a very big company".

      It could well be the case that no organization in the world has spent more on cheese than the U.S. government. That wouldn't make me want to eat it.

      While true, I am sure, both of the above comments reflect your own biases.

      A) It is entirely possible that Microsoft could have spent less than every company on security training. They did not. Whether or not this is noteworthy is up to the reader, but unless Microsoft is in fact larger than every other 'very big company', then it stands to reason that they did something different. You're not arguing the effectiveness, the commonality, or any other point. You're just somehow equating 'big' with 'most sec

      • Oh, I am absolutely biased against Microsoft. Admitted freely, right here. In the aggregate, they suck.

        And I'm biased against bland cheese, too, because there are so many hard-working cows, goats, and sheep out there making really delicious cheese that I don't want to see their efforts swept aside in a sea of mediocrity.

        • Well, I try not to be biased against Microsoft, some of their products (in my opinion) are actually better than their competitors were Excel (very polished and usable spreadsheet) and Visual Studio (slightly buggy, but very well integrated). Well, I decided to check out Windows Phone 7, after all, Windows 7 is much better than XP.

          It sucked, it was just terrible beyond compare, things were slow, badly laid out, hard to read and slow to navigate. I just have to think to myself, why is Microsoft with its resou

      • by rwa2 ( 4391 ) *

        Hmm, well, you could also make the argument that $LARGE_DEFENSE_CONTRACTOR spends more on ethics training than any other @GOVERNMENT_CONTRACTOR, but how does that correlate with the number and impact of misconduct from procurement scandals they've been implicated in? Is integrity measured by $($scandals+$fines)/$(training hours) ?

        Good cheese, like fine wine, smells like $hi+. But we eat that $hi+ up all the same! I don't know where I'm going with this.

      • by lennier ( 44736 )

        While true, I am sure, both of the above comments reflect your own biases.

        Sadly, when it comes to security, reality has a well-known anti-Microsoft bias.

        • by BobMcD ( 601576 )

          Surely, but even when they try harder, they get negativity for that, too.

          It's a sad state of humanity where even if MS fixed everything and was the single greatest product ever, slashdot would still trash them for it.

      • "Whether or not this is noteworthy is up to the reader"

        It *is* noteworthy, probably not in the intended way.

        "Stackpole spending a decade at Microsoft. While Microsoft is chided for creating more insecurity than security, it is worth noting that no organization in the world has spent more on training its staff and developers on security than Microsoft. "

        If Stackpole spent a decade at Microsoft, as implied, related to security tasks and Microsoft spent that much time and money to achieve such bad results, may

    • by TDyl ( 862130 )
      no organization in the world has spent more on cheese than the U.S. government

      That would be "Freedom Cheese" & transfat-full canned cheese I suppose, not decent French, Swiss, German or English cheeses?
    • by gmuslera ( 3436 )
      It reads "Microsoft tried to teach them what not to do, and they misunderstood the not part"
    • Re: (Score:3, Insightful)

      by lennier ( 44736 )

      Indeed. It's results that matter, not expense. Whatever it is that Microsoft is doing, they're obviously still doing it wrong when it's 2010 and there are still new buffer overflows discovered each month in Internet Explorer.

      • by jd ( 1658 )

        Not necessarily wrong. If they have N times as many lines of code to audit, they need to spend an absolute minimum of N times as much just to stay on level pegging. Spending N/2 times as much is still more, but it isn't usefully more.

        Then there's program arcs. You can't just validate each line of code, you have to validate each arc as well. Windows 7 probably has many, many more program arcs than say, oh, Photoshop. At least, I hope so. If you test twice as many arcs but your code has a hundred times as man

        • Re: (Score:3, Insightful)

          "If they have N times as many lines of code to audit, they need to spend an absolute minimum of N times as much just to stay on level pegging."

          That's exactly the point: with regards of secure development, if it's about auditing, then you are doing it wrong.

  • "While Microsoft is chided for creating more insecurity than security, it is worth noting that no organization in the world has spent more on training its staff and developers on security than Microsoft. "

    That's not worth noting at all, microsoft has a bigger staff than any software development company in the world. Them spending $10 to train each employee on security would still be more than spending $100,000 to train each employee at a small 9 employee security firm.

  • My napkin doodle of a one-legged pirate going `Arrrr!' is arguably the best security book ever. What does that expression mean, in reality?
    • It usually means that if you were to consult a panel of experts - there would be a debate.

      It does not mean that "someone, anyone, could argue for it" like you seem to think.

      • by dfsmith ( 960400 )

        The dictionaries (Webster's, American Heritage, don't have my OED handy) disagree. Therefore I concede your point is arguable. B-)

        (However, you did make the assumption that I am not an expert in the subject.)

        My point is that the word adds nothing, and its only effect is to make me sigh because when I see it, I know that the reviewer out of his/her depth. Is it the best security book ever, or is it not? I want answers, dammit!

        • Well how do you FOR SURE say that something is THE BEST or not? For that you'd need to have access to all of the security books ever and thoroughly gone through and evaluated all of them and ranked them too. Then as soon as a new book is released you must do the exact same process.

          Arguably adds the effect of, "Yes - it IS the best security book out there as far as we know. It's entirely possible there is a better one, but we don't know of it. Someone would have to argue for it"

    • by jd ( 1658 )

      The exact translation of Arrrrgh is unknown, but seems to involve the translator being sliced up with a cutlass before walking the plank.

  • by Anonymous Coward

    Let's not confuse what this book is about...this is about systems, development and engineering. That does not encapsulate "information security strategy" or even "information security" as a whole. There are many other moving parts including governance, management, culture, people and things that require diligence beyond technology. Way too many people describe information security using the wrong terms. We need to be specific about what we're talking about and also discuss how these components fit into

    • by al0ha ( 1262684 )
      Agreed - and this viewpoint is specifically applicable to the times we now find ourselves.

      We are at the beginning of a new era of humanity, and whether our descendants praise this generation or curse us depends a lot on what we choose to do now. The problem is we are making a lot of choices based on little or no comprehension of potential future consequences.

      For example, the current mad rush into the *cloud* with data by governments and businesses for the sole purpose of saving a few bucks in the sho
  • by gweihir ( 88907 ) on Monday November 15, 2010 @03:51PM (#34235422)

    The problem is that while "Security Engineering: A Guide to Building Dependable Distributed Systems" does give a lot of interesting details, it is unusable as a guide and it is not an engineering book. I found it to be basically worthless, except for security-junkies that can use it as bedtime reading material. The problem is that it has no discernible systematics, but instead is a collection of said details.

    Even calling is a good book is wrong, as it spectacularly fails to achieve any worthwhile purpose with regard to engineering or science. My advice is to not buy it. The money is better spent on almost any other purpose.

    • Totally agree. This book gets great reviews because it is entertaining, but fails totally as an "guide". It will not turn anyone into a security practioner.

      Regarding the author, while his heart is certainly in the right place, his research has erred a little on the sensatianalistic side ("Chip and Pin is Broken!"). I will have a look at this book, but my expectations are low.

  • by CodeBuster ( 516420 ) on Monday November 15, 2010 @04:15PM (#34235696)
    Despite the oft heard complaints of insufficient designs and botched implementations, one rarely hears one of the primary reasons for poorly secured software: the powers that be really hate paying for it . Indeed, it seems that many organizations, for profit companies in particular, would rather wait until someone sues them or simply purchase insurance against the consequences rather than spend time and money on something they perceive as being of little real value. If we software developers are told to finish the project on time and within budget or they will get someone else (i.e. do it or we will fire you and outsource it to somehow who will say "yes") then we have to do what the people who write the checks want. Most software failures result in loss of wealth, not loss of life, so companies have insufficient incentive to spend time mitigating the problem. In summary, the software engineers are capable and willing but management doesn't want to "waste time" with security. Until that changes, no amount of technical analysis of why software is insecure is going to matter much.
    • by quanticle ( 843097 ) on Monday November 15, 2010 @05:04PM (#34236248) Homepage

      Security holes, like illegal toxic waste dumps are negative externalities. Without some kind of regulation and enforcement, rational individuals and companies will continue to create more security holes simply because they're not paying the true cost of insecure software.

      • by durdur ( 252098 )

        Security holes, like illegal toxic waste dumps are negative externalities.

        They are not strictly externalities, because some of the bad effects can and do rebound on the business entity that is causing the problem. At least they can involve loss of reputation, and they can include the cost of emergency ex post facto mitigation measures, if a security problem is severe. Other financial or legal consequences are also possible, but license agreements typically include a limitation of liability, which provides some insulation.

        • The presence of a negative externality doesn't mean the person or organization responsible gets off scot-free. It means that they aren't hit with the full cost of the problem they've caused. I would argue that security holes are a classic case of a negative externality as the organizations responsible for creating them pay a very small amount compared to the economic damage that these security holes cause.

  • Seems like the same old blather. I don't see anything in the authors credentials that lend any credibility to what he's proposing.
  • "...with detailed requirements and specification from start-up"

    So by it's own admission, it won't work.

Don't get suckered in by the comments -- they can be terribly misleading. Debug only code. -- Dave Storer

Working...