Slashdot Log In
How to Cheat at Managing Information Security
Posted by
samzenpus
on Wed Sep 27, 2006 02:47 PM
from the keep-it-secure dept.
from the keep-it-secure dept.
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.
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
You can never do away with a firewall. Ever. (Score:4, Insightful)
I'm not sure the the comments about firewalls are accurate. Sure, if every software maker paid attention well to security, then we'd be in a lot better position than we are now, but I'm not necessarily sure that building firewall-level security into every application is a good thing.
For example, if I want to restrict the access to a particular service to a few ip addresses, I'm more likely to do this on my firewall than on the service myself. Sure, the people who make the service could include that functionality, but I like the separation of security out away from the application. I like the fact that I control all my access in one place, and not across hundreds of application-specific config files. I believe modern filewalls can do all sorts of clever things such as coping with DoS attacks, stateful examination of network traffic etc etc etc. Can you imagine what it would be like if every single service had that functionality built in, but implemented slightly differently and with slightly different types of weakness in each one? Think of the duplicated functionality and bloat!
There's no such thing as software which is immune to malicious attack, but I like to keep my security weaknesses all in one place, and minimize them buy buying my firewalls from a company that has track record and experience in security issues, rather than a company that makes an ftp server for a living.
Defense in depth. (Score:5, Insightful)
With a firewall, it is a single point that can be cracked. If that is your only security point, you'll be wide open if it is every cracked. And "cracked" also includes "someone brings in an infected laptop".
Now, on the workstation level
#1. No services running that aren't absolutely necessary.
#2. No open ports that aren't absolutely necessary.
#3. Any open ports/running services will ONLY accept connections from my servers / admin workstations. Anything else is logged and I am alerted.
Most of this can be accomplished with an IDS. I'd like the workstation firewalls AND the IDS. Having multiple checks is good. (and the firewall, you need the firewall)
Parent
Re: (Score:2, Insightful)
Of course, you're absolutely correct. Anyone who thinks that a single security device/solution will solve all their problems is barking. I was thinking from a more datacenter-oriented point of view, whereby I have lots of boxes, which may all only run a couple of services each (I have webservers, FTP servers, DNS servers, DB servers etc). The rules governing what data can go from A to B tend to get quite complex, and a centralised firewall solution to managing this is the most secure and maintainable.
Of co
Re: (Score:2)
Re: (Score:2)
You win the "wrong tool for the job" award! Unless IP addresses follow your users and you have lots of anti-spoofing technology, you're biffin it, bud.
Re:You are missing the point (Score:5, Insightful)
Parent
Re: (Score:3, Interesting)
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
Re: (Score:2, Insightful)
Re: (Score:2)
At that point, suspension of disbelief goes out the window :)
Re: (Score:2)
1. Buy faulty software
2. Hire incompetent system administrators.
The fact that both of the above not are the exception but the norm
says something about the software industry that I dont like.
Re: (Score:2)
Of course, at this point, most people are behind a router anyways, which has a firewall...
So yeah, if you look in terms of "specifically bought as firewalls", then yes, I'm sure the corporate sector wins out. But in general, if you consider
auditor jokes thread.... :) (Score:5, Funny)
Re: (Score:2)
They are the people that go around after a battle and shoot the wounded.
Comparison To Security Engineering? (Score:2)
http://www.cl.cam.ac.uk/~rja14/book.html [cam.ac.uk]
Re:Comparison To Security Engineering? (Score:4, Funny)
Parent
Re: (Score:3, Funny)
Mod +4 Good Analogy
70% Funny
30% Good Analogy
Re: (Score:2)
Actually, Senator Ted Stevens has released a good introduction to the basics [wikipedia.org] into the public domain. If you're having trouble with the link above, let me know and I'll see if I can send you an internet.
Re: (Score:2)
Ain't that the truth (Score:5, Insightful)
This same principal applies to a great number of jobs in IT. If it's your job to create content for display on the Internet/Intranet and you aren't given the proper access and tools to get the job done, it is often your fault for the failure, even though you're at the mercy of others. Same goes for bad project management; if a project is slow or fails, it's not because the project manager was an ignorant troll, but was in fact due to the "inability of programmers to meet their goals," even though the goals and timelines were unreasonable and ultimately futile.
Re: (Score:3, Insightful)
People need to work as a team and be evaluated as a team. If upper management accepts the scapegoat, then they probably created the problem in the first place. Otherwise they need to resolve the issues as a group.
Re:Ain't that the truth (Score:5, Interesting)
-- Robert A. Heinlen, _Starship Troopers_
Parent
General thoughts.... (Score:4, Insightful)
I'm *not* saying that we don't need or shouldn't respect people who make a point of studying information security. But rather, that these people are most effective when they're working to build security appliances, hardware, and software that will eventually be purchased by I.T. staff. Or perhaps, when they have a specific task related to tracking down fraud in a telecommunications environment.
In most corporations, it seems like the person or people appointed as "information security" are really just getting paid to be the fall guy(s) if and when something goes wrong. They want someone to point a finger at. The "infosec specialists" I've run across rarely have very many useful computer skills to offer a business. Rather, they're mainly good at writing up policies and procedures they insist everyone should follow for "safe computing". They can go into great detail about why a particular update patch for a router or TCP/IP stack is important for preventing a theoretical attack - yet they can't even troubleshoot a single hardware failure due to bad RAM or a failing hard disk in a workstation.
The "rank and file" I.T. staff and management probably have just about as good a track record of keeping a given computing enviroment reasonably "secure", as long as they're diligent about keeping things updated and patched, and following some common sense procedures. They may not know (or care!) about all the technical details of why a given patch is effective, but it doesn't end up making much difference.
Re: (Score:3, Informative)
Re: (Score:2)
For starters, I'm of the opinion that the user *must* come first - so maybe I'm fundamentally at odds with the basic premise of their work. But from 15+ years of experience with computers and I.T., I've become convinced that usability MUST trump security, or else you've wasted your money. The trick is to make things as secure as possible, without cro
Re: (Score:3, Insightful)
Yes, you are at odds with the basic premise. What comes first is the risk analysis. What are you trying to protect? What are the threats? Who are the agents attacking it? Are you trying to keep something confidential, or are you trying to preserve integrity, are you trying to keep availability of the system?
Then, when you know what you are trying to achieve, you can then
eh? (Score:2)
You're coming at this wrong. For large companies, yes, the users come first. But there are a great
Re: (Score:2)
There is a very simple rule for figuring how secure a system needs to be: It should cost more to break into the system than the information it contains is worth.
A lot of day to day information doesn't need much security because it will be obsolete at the end of the day. On the other end, there are secrets that are the entire basis of your business, and these have to have real security. An example of this would be the formula for Coca-Cola. There is no way it belongs on any networked computer, because the e
Re: (Score:2)
I agree that most security officers don't know jack about what patches are truly needed and why, just that they are needed to reduce the risk to business continuance. IOW, they are liasons to the people who have other things to do besides deploy updates and who need to learn why sysadmins would ban those bloody sticky notes from any office with a PC in it.
They are business people, not IT people, so stop treating them as such.
Soko
Re: (Score:2)
Really? That's weird. Where I work, the only staff who actually have the skills and methodical nature to effectively troubleshoot problems are the "infosec specialists". The desktop support people, the network analyst, the system admins, they all just automatically say "It must be a firewall/IPS/AV/ACL problem" and don't bother to do any sort of fault isolation, or if that
Memories (Score:5, Interesting)
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.
Re:Memories (Score:5, Interesting)
Of course the first thing the auditors want to do is plug into our network so they can get their email. I said no, because if we do they it violates SOX and we fail their audit. They asked how they're supposed to audit us then if they can't use their e-mail? Not my problem, refer up to management :)
I actually won this round. We ended up isolating a portion of the network so they could have access straight to the Internet.
Parent
Re:Memories (Score:5, Funny)
We had a similar discussion with our auditors. It wasn't SOX, it was SAS70, but still a process audit. What I thought was hilarious was when I walked past the conference room that the 3 auditors had occupied, and there sat their 3 laptops, screens unlocked and nobody in the room. The urge to set their background image to goatse was almost overwhelming, but I thought better of it.
Parent
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The Necessity of Auditors (Score:4, Insightful)
I'm not saying they are crooked... I'm saying a lot of them rebel against structure, employ "fly by the seat of the pants" methodology, refuse to participate in process tracking, avoid completing paperwork, and think that the "art" of their business means they should be able to do things their way.
I think IT workers in general (probably including me) need to be watched like hawks. Otherwise we end up with broken chains of approval, unmaintainable code, and important things resting on the shoulders of "the guy in the room". You know, that guy who never provides status reports and vanishes for months at a time, emerging with a completed product that may or may not do what is intended.
Re:The Necessity of Auditors (Score:5, Interesting)
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.
Parent
Re: (Score:3, Interesting)
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.
Audi
Re: (Score:2)
Re: (Score:2)
Claims to Be? (Score:2)
I work in a SOx-affected company as well, although we are on the Canadian side. Every year we go through auditing.
So yesterday I'm looking into an open problem issue, one that has to go through several channels, and that must be tracked. And you know what the UNIX guy has put for the sum total of information relating to his part
and you wonder why your employees think you suck (Score:4, Insightful)
Security Bricks (Score:2, Informative)
Then vs Than (Score:2)
than [reference.com]
At the very least, could book reviewers and submitters please learn the difference between these two words!
Re:Be like Slashdot (Score:5, Funny)
Pot, I'd like to introduce you to my good friend kettle. Kettle, this is pot. I believe you two have a lot in common, so play nice, OK?
Parent
Re: (Score:2)
Perhaps it's time you started using FireFox so that you can install the "intentional irony detector" plugin.
Re: (Score:2)
Yeah, I suspected intentional irony for a couple seconds, then decided it was a lot more likely to be a case of unintentional idiocy. And I'm already using Firefox.
Re: (Score:3, Funny)
Re: (Score:2)
And emphasises the point even more firmly.
Re: (Score:2)