Slashdot Mirror
How to Cheat at Managing Information Security
Ben Rothke writes "Mark Osborne doesn't like auditors. In fact, after reading this book, one gets the feeling he despises them. Perhaps he should have titled this book 'How I learned to stop worrying and hate auditors'. Of course, that is not the main theme of How to Cheat at Managing Information Security, but Osborne never hides his feeling about auditors, which is not necessarily a bad thing. In fact, the auditor jokes start in the preface, and continue throughout the book."
Read the rest of Ben's review.
How to Cheat at Managing Information Security
author
Mark Osborne
pages
302
publisher
Syngres
rating
8
reviewer
Ben Rothke
ISBN
1597491101
summary
The adventures of an information security professional and his efforts to secure corporate networks
The subtitle of the book is 'Straight talk from the loud-fat-bloke who protected Buckingham Palace and ran KPMG's security practice'. Essentially, the book is Osborne's reminiscence of his years in information security; including the good, the bad, and more often then not, the ugly.
The book is written for someone looking to develop an information security program, or strengthen an existing program, to ensure that all of the critical technology areas are covered.
The thirteen chapters of the book cover the main topics that an information security manager needs to know to do their job. The author candidly notes that this book is not the most comprehensive security book ever written, but contains most of the things a security manager needs to get their job done. The author also observes that information security is different from other disciplines in that there are many good books about disconnected subjects. The challenge is getting the breadth of knowledge across these many areas, which is quite difficult. The challenge of information security is to effectively operate across these many areas.
Chapters 1 and 2 deal with the information security organization as a whole, and the need for information security policy. Chapter 1 details the various areas where a security group should be placed, and describes the pros and cons of each scenario. As one of the scenarios which place information security below the head of audit, Osborne notes that 'if you have any sort of life, you don't want to spend it with the auditors, I promise you'.
Wherever the security group is placed in an organization, its ultimate success or failure is likely to be determined by its level of autonomy and independence. Unfortunately, in far too many organizations, information security is not given that liberty. It is often placed in a subservient role to groups with opposing interests. Any security group or security manager placed in such a situation should likely start working on their resume.
The scenario is described in 'Practical Unix and Internet Security' where author Professor Gene Spafford spells out Spaf's first principle of security administration. This principle states that 'if you have responsibility for security but have no authority to set rules or punish violators, your own role in the organization is to take the blame when something big goes wrong'. Spaf's principle is a cruel reality faced by many of those responsible for information security.
Between those chapters and a few more auditor jokes, Osborne makes the blatently obvious observation that wherever possible, one should eradicate single points of failure. As a corollary to this, Osborne notes that while trying to eliminate these failure points, companies will often build redundant systems. Part of their admiration for these redundant systems is the hope that this will simultaneously reduce performance bottlenecks. But these companies do not realize that the routers, firewalls and switches are not the bottleneck, rather it is the software application which is the bottleneck.
Osborne plays the role of contrarian in chapter 8 when he asks why we need firewalls. He notes that if every database maker, operating system programmer and CRM/ERM vendor put as much effort into security as the firewall vendors do, then there would be no need for firewalls. Furthermore, if each system administrator worked as hard on security as the typical firewall administrator did, and devoted as much time to hardening their servers and laptops as they did; then centralized firewalls would likely not be needed. Given that the firewall-free reality is not happening any time soon, chapter 8 provides a lot of good information on everything you need to know about firewalls.
Chapter 9 is about one of the most maligned security tools, the IDS. After providing an anecdote about a network manager who did not understand the fundamentals of how DHCP operates, and how he used Snort to debug the problem; Osborne provides a meaningful piece of security wisdom when he notes that IDS can help any network or security person understand network traffic. These devices can even give you information on new attacks and how they can be mitigated. But for an IDS (or any security hardware or software device for that matter) to be truly useful, a security professional needs to understand their IT infrastructure, the mechanics of networks and applications and the risks involved. Those who don't understand those three things will only be able to use these security technologies with minimal benefit.
Overall, How to Cheat at Managing Information Security, is an informative and often entertaining introduction to information security. For those that want to get a good overview of the core elements of information security, or strengthen their existing knowledge base, they will find this book to be an informative and valuable read."
You can purchase How to Cheat at Managing Information Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The subtitle of the book is 'Straight talk from the loud-fat-bloke who protected Buckingham Palace and ran KPMG's security practice'. Essentially, the book is Osborne's reminiscence of his years in information security; including the good, the bad, and more often then not, the ugly.
The book is written for someone looking to develop an information security program, or strengthen an existing program, to ensure that all of the critical technology areas are covered.
The thirteen chapters of the book cover the main topics that an information security manager needs to know to do their job. The author candidly notes that this book is not the most comprehensive security book ever written, but contains most of the things a security manager needs to get their job done. The author also observes that information security is different from other disciplines in that there are many good books about disconnected subjects. The challenge is getting the breadth of knowledge across these many areas, which is quite difficult. The challenge of information security is to effectively operate across these many areas.
Chapters 1 and 2 deal with the information security organization as a whole, and the need for information security policy. Chapter 1 details the various areas where a security group should be placed, and describes the pros and cons of each scenario. As one of the scenarios which place information security below the head of audit, Osborne notes that 'if you have any sort of life, you don't want to spend it with the auditors, I promise you'.
Wherever the security group is placed in an organization, its ultimate success or failure is likely to be determined by its level of autonomy and independence. Unfortunately, in far too many organizations, information security is not given that liberty. It is often placed in a subservient role to groups with opposing interests. Any security group or security manager placed in such a situation should likely start working on their resume.
The scenario is described in 'Practical Unix and Internet Security' where author Professor Gene Spafford spells out Spaf's first principle of security administration. This principle states that 'if you have responsibility for security but have no authority to set rules or punish violators, your own role in the organization is to take the blame when something big goes wrong'. Spaf's principle is a cruel reality faced by many of those responsible for information security.
Between those chapters and a few more auditor jokes, Osborne makes the blatently obvious observation that wherever possible, one should eradicate single points of failure. As a corollary to this, Osborne notes that while trying to eliminate these failure points, companies will often build redundant systems. Part of their admiration for these redundant systems is the hope that this will simultaneously reduce performance bottlenecks. But these companies do not realize that the routers, firewalls and switches are not the bottleneck, rather it is the software application which is the bottleneck.
Osborne plays the role of contrarian in chapter 8 when he asks why we need firewalls. He notes that if every database maker, operating system programmer and CRM/ERM vendor put as much effort into security as the firewall vendors do, then there would be no need for firewalls. Furthermore, if each system administrator worked as hard on security as the typical firewall administrator did, and devoted as much time to hardening their servers and laptops as they did; then centralized firewalls would likely not be needed. Given that the firewall-free reality is not happening any time soon, chapter 8 provides a lot of good information on everything you need to know about firewalls.
Chapter 9 is about one of the most maligned security tools, the IDS. After providing an anecdote about a network manager who did not understand the fundamentals of how DHCP operates, and how he used Snort to debug the problem; Osborne provides a meaningful piece of security wisdom when he notes that IDS can help any network or security person understand network traffic. These devices can even give you information on new attacks and how they can be mitigated. But for an IDS (or any security hardware or software device for that matter) to be truly useful, a security professional needs to understand their IT infrastructure, the mechanics of networks and applications and the risks involved. Those who don't understand those three things will only be able to use these security technologies with minimal benefit.
Overall, How to Cheat at Managing Information Security, is an informative and often entertaining introduction to information security. For those that want to get a good overview of the core elements of information security, or strengthen their existing knowledge base, they will find this book to be an informative and valuable read."
You can purchase How to Cheat at Managing Information Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I suppose my point in telling that is that you can look at auditors two different ways. Either they're there to help you, or they are there to get in your way and point fingers. I believe that most genuinely good auditors try to be more like the former and less like the latter. And you can learn a lot from them if you remain objective and cooperative. God help you if you get the other kind though as they are usually just nothing but self-promoting tattle-telling toadies.
What if the Hokey Pokey really is what it's all about?
To the contrary. Necessary structure is good, and IT workers know that. A lot of managers are bad. They try to impose methodologies that do not fit the problems, and demand excessive structure and paperwork. They demand schedules, and then superficially alter them until what might have been a reasonable best guess is now a death march. They think things should be done "their" way, and get in the way. That is extremely irritating when they demonstrably don't know what the heck they're doing, and can't or won't see that. IT workers don't want to hand those guys any more rope than they must; they know it's only going to be used to hang everyone. What you see as rebelling against structure itself, I see as rebelling against the abuse of structure, and against those who think the "art" of management means they don't need to know anything about the technology or science, let alone the boring technical details. They only need to know how to make engineers be productive, avoid being blamed for problems, and get the credit.
Of course a classic way to avoid blame is to make stupid rules and then point to the engineering geeks' supposed lack of discipline for not following those rules. Really great when there's a handy stereotype available. Most people aren't going to provide accurate status reports with useful content if the main use of it will be against them. I'd say not giving a status report at all is more honest than giving a status report that's nothing but evasions, fluff, misdirection, boilerplate, and such garbage.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Well, I call bologna..
I worked as a developer at LARGE company - as their credit card server admin & developer (actually a small part of my other tasks).
My first two years, auditors wanted to get copies of the credit card records - and I refused. I told them I could allow them access to review them at the location and they still wanted to have copies. Nope.
I left the company - and less than a year later, well, you know the story. Auditor gets copies on laptop, laptop gets stolen. Big news story.
Auditors blow goats - if those guys are serious about security then they'd spend less time trying to sell us services and more time evaluating their own process. They should know better than to take records offsite unprotected in any form. And yet, they couldn't see the problem. I just don't understand.
I said no... but I missed and it came out yes.
I disagree. In a datacenter, you'll probably have each service you provide divided up into various 'cells'. Each one of these cells may connect to the outside world in some way, either through the internet, or some large MPLS cloud, or whatever. Each cell will probably be split up in a number of different ways, traditionally a core and a DMZ. You probably have some sort of management lan infrastructure behind the whole thing as well. You might also want to have some of the cells communicate with each other on the backend, or to talk to a common db.
Ok, so you've got firewalls between the WAN and your DMZ, firewalls between the DMZ and the core, firewalls between the core backend and any other cell, and firewalls between the management network and the cells. The situation tends to be slightly more than "You've got a datacenter behind a firewall".
The whole point of this setup is so that if one portion of the datacenter is compromised, you isolate that to the smallest possible area you can. If I want to only allow my management lan access during the hours of 10am and 4pm (silly, but bear with me), where do I configure that? On the firewall? Perhaps?
Firewalls and routers are very different things. One tells the network traffic where to go, the other tells it if it's allowed to go there. Of course, this is invisible to the client, who just sends packets off which either find their route (allowed and routable) or don't (either routable and not allowed, or just not routable). Even if all of my applications and OS's wern't fundamentally flawed, I'd be an idiot not to use firewalls, because of the amount of control they allow on the network. If I want to shut down access from one network on a specific port, I can do it quickly and easily on a firewall. This isn't even possible for the application to do a lot of the time as it's just seeing packets coming from the router, and doesn't necessarily know where they started out life.
There is nothing interesting going on at my blog
"Authority and responsibility must be equal - else a balancing takes place as surely as current flows between points of unequal potential. To permit irresponsible authority is to sow disaster; to hold a man responsible for anything he does not control is to behave with blind idiocy."
-- Robert A. Heinlen, _Starship Troopers_
Why doesn't the gene pool have a life guard?