Slashdot Mirror
Security Strategy: From Requirements To Reality
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.
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.
necks really should have bones going all of the way around them
in a book!
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... )
check out the Mp3 Garbler I built!
Your servers need a blanket.
Oh, you thought I meant THAT Linus...
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.
Facebook security?
Yours In Anchorage,
Kilgore T.
"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?
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 the larger security strategy. Strategy itself consists of understanding an organization's business, its nuts and bolts, its workforce, the cost, its risk tolerance and many other areas. The way you develop or engineer or even maintain a system is a small slice of the areas which need attention. Information security strategy is not risk management and is by no means is limited to threats x vulnerabilities = risk.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
In a environment where features are the top priority (aside from time) and being agile to feature creep even higher...your products are ultimately customer driven.
And if your customer doesn't really know the problem domain, which is 98% of the teams/times out there, you have the case of the 'blind leading the blind'.
That's why we have so many security problems nowadays... compared to 30 years ago.
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.
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.
We all know what to do, but we don't know how to get re-elected once we have done it
There is a myopic view that it is systems which are vulnerable, it not the system its the resource and the information.
Do I car if you steal some cycles from my CPU or my credit card information?
The problems with most systems is that the security metadata is not transferable across systems so there is a manual process of recreating the security metadata when the information flows across the systems. Yes we have enterprise identity management but the enterprise object metadata is pathetic. You need both to apply business security rules.
Security is the instantiation of business rules, system security is an empirical devolution of this point.
Seems like the same old blather. I don't see anything in the authors credentials that lend any credibility to what he's proposing.
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
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.
We all know what to do, but we don't know how to get re-elected once we have done it
"...with detailed requirements and specification from start-up"
So by it's own admission, it won't work.
Ok, this does make sense.
Everyone wants security, but that is true, no one wants to pay for it.