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'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.
There is nothing interesting going on at my blog
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.
GetOuttaMySpace - The Anti-Social Network
This may be a little off-topic, but I can't help but feel that the job title of "information security specialist/officer/manager/etc." is generally bogus from the start, at least as it pertains to "end users" of technology.
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.
The only reason I'd like to see decent firewalls on the workstations is for more "depth" to my security model.
...
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)
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.
I'm not sure it's possible, let alone feasible.
How is my application supposed to know how my network is configured? Do I have to let every application snoop into my network config? That doesn't sound secure to me...
My firewall knows about my network. My applications don't. My firewall can tell if a packet came from inside or outside the network; and dispose of it accordingly if the IP address doesn't match basic traffic analysis (like packets from the ouside world that claim to be from inside the network). Applications can't do that without the same intimate knowledge of my network my network has. I shouldn't have to give it to them.
Let firewalls keep the bad packets out. Let applications deal with the data layers. It's that simple.
Auditors are necessary because IT workers often can't be trusted.
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.
Ok, lets assume that there is a huge datacenter behind the firewall. What does the firewall do to protect the datacenter? Generally, you do not allow direct inward access from the Internet into a DC proper. Rather, you use a DMZ to host exposed nodes. So in the end, for the DC, the firewall is just a router. It allows traffic from select DMZ nodes to access hosts inside the network. That's really the function of a router. However, we often filter as well to ensure that only the minimum ports and services that are required are passed. Why do we do this? Because we are concerned that the DMZ nodes might get compromised and be used as a gateway into the environment to compromise nodes on the internal network. Why are we concerned about this? Because we have come to accept that the vendors of server platforms, operating systems, middleware, databases, etc ship fundamentally flawed products. They are buggy, exploitable and are not carefully coded to prevent compromise. We trust firewalls, because they are very carefully coded and great pains are taken to ensure that they cannot (generally) be compromised. That is the author's point. Let's spend the time ensuring that products are as well coded as the firewalls and we do not need a firewall. Is this likely to happen? Probably not, but it is a valid point.
TECMATIC - Intelligent Technology News
You are STILL missing the point. If applications were written so they couldn't BE compromised, then it wouldn't be necessary to have firewalls. And there's always a way in - via the VPN that the systems administrators use if nothing else. Hack their workstation at home perhaps. Firewalls give a false sense of security. You *think* no one can get at your applications, so you get sloppy about other things such as IDS/Tripwire and so forth. I've seen it in my current workplace, and it's just the wrong attitude to take. Firewalls are a BACKUP because you know the software is faulty somewhere. If you have them in place for any other reason then you need to rethink their purpose.
... what a thorough waste of resources.
Most routers route traffic in a transparent manner, so yes the application can see where it comes from. Ever seen your router listed in your Apache logs? No? I didn't think so. I recognise that rinetd and similar tools that run in user space are less transparent, but those are generally hacks anyway and the firewalls can't tell the source of those packets either.
The firewall is not necessarily the best place to configure LAN access either. All that does is increase support calls "it's 4:05 pm and my LAN access is down". Waste of administrator time. Better to have a policy on your AD server. And if you don't have centralised workstation management then that's a different problem entirely. In a large organisation the team managing the firewalls ("Security") is separate from the workstation team which is separate from the UNIX server team which is separate from the Windows server team which is separate from the network team. So if your machine gets compromised whose fault is it? The server team? Security? Who made the mistake? Hooray, we had a firewall so it's not our fault, let's pass the blame on to the security team, who will pass it back saying that you wanted that port to be let in
Yes, I use firewalls. Yes, I think they're necessary. Yes, I think that application developers should all be required to attend a course on how to code in a secure manner. The number of hacks I have seen to get something working makes me shudder.