Slashdot Mirror
The Pragmatic CSO
Ben Rothke writes "The
Pragmatic CSO: 12 Steps to become a
Pragmatic CSO is worth reading for one sentence on page 12
which states: It's not about technology — it's about
business. The even better news is that the book is full
of insightful ideas like that, on how information should work, and how to make
it work in today's large enterprise organizations. One of the mistakes
many security professionals make is that they think of security for its own
sake, when security is simply meant to support the business.
CxO's could care less about encryption key lengths and operating
systems. While they don't care about the technical
details, the people from information security often mistakenly communicate to
them in those terms." Keep reading for the rest of Ben's review.
The Pragmatic CSO: 12 Steps to become a Pragmatic CSO
author
Mike Rothman
pages
235
publisher
Security Incite
rating
9
reviewer
Ben Rothke
ISBN
None - self published
summary
Pragmatic, insightful and valuable looking into making security work
The book notes that
there are three main causes to the poor state that information security finds
itself in today in far too many organizations:
Security is viewed as a technical function
- Security staff are often part of the technical
teams, but not members of the management team.
The bad guys are getting better
- In years past, attackers
would get your attention by playing music in the background as their virus
infected your workstation. Today's attacks are
built around stealth techniques. Attackers do
their best to hide from your IDS, and often easily do so.
Auditors are tougher-
Both internal and external auditors are finally getting the power they
deserve. The days of having them rubber stamp the
audit are slowly coming to a close.
The Pragmatic CSO:12 Steps
to become a Pragmatic CSO details a 12-step program, which is
a structured program on which to build a strong information security
program. The book goes through those steps
as a way to keep you, as the CSO, focused on the goal.
That goal is to demonstrate the value of information security
management and the level of security to the internal and external
auditors.
The books 4 sections and 12 steps are structured similarly, beginning with what you will learn in the specific step, a dialogue-based introduction akin to an AA (Alcoholics Anonymous) session, and an action plan for each step. Personally, I found the AA dialogues a bit cheesy, and by step 6, found them a bit annoying. Aside from that issue, the book is a highly valuable guide in which a new CSO can use to directly assist them in their job. A new CSO is recommended to use the guide in their first 100 days in office. Such an approach can spell the difference between success and failure.
As its title implies, the book is all bout being pragmatic. This practical approach is needed, as step 2 notes that it is hard for many security professionals to get beyond the typical vulnerability-centric definition of success. It is not about how many vulnerabilities are found, rather the pragmatic way in which their are handled.
Part of this pragmatic approach is being realistic of the state of security in your origination. Step 7 underscores this when it shows how a CSO should never underestimate to things : the ability of the bad guys to make you look bad, and the ability of users to do something really stupid. The preceding is just one example of many where the book shows the reader what security is like in the real-world, as opposed to the often described pristine cryptographic world of security when Alice and Bob are involved.
Perhaps the most important point the book makes is that pragmatic CSO's have no religion when it comes to security and technology, besides doing the right thing for their business and protecting their assets. Far too many people in security and technology turn technology choices into religious wars, most of which center around Windows, Linux, Cisco and Juniper.
Step 11 details metrics and benchmarks and has a number of constructive questions in which to benchmark against. The areas of questions include effectiveness, awareness, attitude and financial. This is needed as metrics and benchmarking are needed to measure how you and your security team are doing, and to identify areas in need of improvement. Benchmarking can also point out areas which your organization differs from the norm. While that is not necessarily a bad thing, it is necessary to know when to follow so-called best practices, or whether to do what is specifically right for your organization.
The Pragmatic CSO:12 Steps to become a Pragmatic CSO is a most valuable book in that it provides fresh, real-world advice, as opposed to generics rehashed best practices. Author Mike Rothman's premise is that today's CSO's need to act more like business people in order to thrive. With firms laying-off back-office technology staff by the thousands, having this front-office approach is not only timely, it may just save your job.
Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The books 4 sections and 12 steps are structured similarly, beginning with what you will learn in the specific step, a dialogue-based introduction akin to an AA (Alcoholics Anonymous) session, and an action plan for each step. Personally, I found the AA dialogues a bit cheesy, and by step 6, found them a bit annoying. Aside from that issue, the book is a highly valuable guide in which a new CSO can use to directly assist them in their job. A new CSO is recommended to use the guide in their first 100 days in office. Such an approach can spell the difference between success and failure.
As its title implies, the book is all bout being pragmatic. This practical approach is needed, as step 2 notes that it is hard for many security professionals to get beyond the typical vulnerability-centric definition of success. It is not about how many vulnerabilities are found, rather the pragmatic way in which their are handled.
Part of this pragmatic approach is being realistic of the state of security in your origination. Step 7 underscores this when it shows how a CSO should never underestimate to things : the ability of the bad guys to make you look bad, and the ability of users to do something really stupid. The preceding is just one example of many where the book shows the reader what security is like in the real-world, as opposed to the often described pristine cryptographic world of security when Alice and Bob are involved.
Perhaps the most important point the book makes is that pragmatic CSO's have no religion when it comes to security and technology, besides doing the right thing for their business and protecting their assets. Far too many people in security and technology turn technology choices into religious wars, most of which center around Windows, Linux, Cisco and Juniper.
Step 11 details metrics and benchmarks and has a number of constructive questions in which to benchmark against. The areas of questions include effectiveness, awareness, attitude and financial. This is needed as metrics and benchmarking are needed to measure how you and your security team are doing, and to identify areas in need of improvement. Benchmarking can also point out areas which your organization differs from the norm. While that is not necessarily a bad thing, it is necessary to know when to follow so-called best practices, or whether to do what is specifically right for your organization.
The Pragmatic CSO:12 Steps to become a Pragmatic CSO is a most valuable book in that it provides fresh, real-world advice, as opposed to generics rehashed best practices. Author Mike Rothman's premise is that today's CSO's need to act more like business people in order to thrive. With firms laying-off back-office technology staff by the thousands, having this front-office approach is not only timely, it may just save your job.
Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Spock or T'Pol?
CSO means "Chief Science Officer," right? Because the article doesn't bother to define it.
"National Security is the chief cause of national insecurity." - Celine's First Law
Security is vital knowledge... as time passes, the criminals get smarter. It is impossible to mitigate all possible threats 100% of the time, but in order to keep the probability of these threats low, you have to be on the same playing field as the criminals. If not, well, you've seen what happened to the Death Star.
I will bend like a reed in the wind.
I read the headline as "the pragmatic SCO", and was thinking "where?"
Do you have ESP?
FTFS:
Step 7 underscores this when it shows how a CSO should never underestimate to things : the ability of the bad guys to make you look bad, and the ability of users to do something really stupid.
Emphasis is mine. Speaking of things that make you look stupid? Irony?
Seriously, this advice works for anything.
Support NYCountryLawyer RIAA vs People
This idea of people focussing on their own job role to the detriment of the overall organisation is very common.
Finance people think hours filling in expenses claims over £30 lunches, support who won't let you install a vital and harmless piece of software because it's against regulations, managers who call so many status report meetings it's impossible to get any real work done... this kind of stuff happens all the time.
A lot of people are self important, narrow minded and don't see the big picture. In other news, water is wet.
I tried discussing security "pragmatically" with our PCI level 1 auditor, and it didn't go well.
He wanted to see an example of all 200+ recommendations, even if it made no sense for our environment.
So yes, don't be arbitrary if you get to make up the rules. But as long as there are large fines assessed by auditors who cling to arbitrary rules than arbitrary security rules are here to stay.
It's not about technology -- it's about business.
No.
The entire IT world currently exists for its own sake. The business world has discovered they can use it, to some extent, but let's not take that too far in ascribing a raison d'etre to all things tech.
We have computers because geeks like toys. In order to afford more toys, we whore ourselves out to the business world... But the relationship ends there. If we can help our employers make more shiny colorful reports measuring how much money we waste on blue vs green widget paint, great, good for them (and the landfills). If not... I can't speak for everyone on Slashdot, but at the end of the day, I go home and do my best not to think about work.
Yet, I still go home, fire up my PC, and continue improving the very skills that make me valuable to my employer (I'll skip the obvious gaming and porn jokes here). I, as I believe of most geeks, do it for its own sake, because I love technology and toys - Not because I have some BS "compelling business case" to dedicate much of my life to technology for the gain of CEOs who wouldn't give me the time of day to spit on me if they came across me dying in the desert.
That's a tough thing for security professionals to draw a distinction with. Everything a company does should weigh the business value of a proposed technology vs the risk of what happens if that technology breaks. So if you have an old firewall or licensing restrictions that won't let you use 3DES or AES for your VPN, and are stuck with DES, the company (CSO) should be weighing the cost of upgrading vs the risk of loss to the company if your DES VPN is broken.
If you have credit data passing across, there may very well be PCI/DSS issues and fines, but if the VPN is just there to pass pictures of kittens from one site to another, you might not care and may not need 3DES or better.
Many security professionals see this as sub-optimal, and will bitch. However as long as the senior management is aware of the risk and has decided it's a risk worth taking, then you've done your job as a security person.
I like music
Business-side executives who think they can manage without understanding anything at all about the technical details are just as arrogant and dangerous to the bottom line as techies who think they don't need to understand anything about the business.
In a wonderful Dilbert cartoon, the PHB says "Reasoning that anything I don't understand must be easy..." and assigns Dilbert an impossible task predestined for failure.
People on both the money side and the technical side need to work for mutual respect and understanding, and both need to be patient enough to listen to, and understand, material that doesn't fall within their specialty.
"How to Do Nothing," kids activities, back in print!
A CSO is a combined sewer overflow. Where a sewer system is old, is was designed to carry both stormwater (rain fall off houses and streets) and sanitary sewage (from inside houses) to an outfall (and later to treatment plants). Modern systems have separated sewers, one for stormwater one for sanitary. Only the sanitary goes to the treatment plant. In the city where I live, the outer parts are modern, but the centuries-old infrastructure downtown is still served by combined sewers. Dry days, the sewage is all sanitary, but rainfall increases the flow. The treatment plant or pumping station capacity would be exceeded and the combined sewage discharged directly to the lake. Now, combined sewer overflow tanks have been installed to store the surcharged sewage until the storm is over, and then pump the sewage back into the system to be treated. Until the combined sewers are eventually replaced, this is the best way to help eliminate the release of untreated sewage to the environment. A pragmatic CSO? Most CSO's don't operate at all in normal conditions, but instantly jump into action the moment the sh!t levels rise beyond the system's ability to deal with it. Is this pragmatic?
If only we could fall into a woman's arms without falling into her hands
Executive management (except CIO/CSO obviously) shouldn't need to understand anything about the technical details. The technical groups should be doing the necessary analysis and giving them the necessary information to make choices about technology initiatives.
The problems come when the execs ignore what their direct reports are telling them, or if the technical people aren't providing the execs the information they need to make the decisions. I don't think trying to educate the execs on the technical details is a very efficient solution to either of those problems, although I suppose it may work with certain managers.
Everybody who's worked/working in business (as opposed to academia, where your success is really just the weight of papers you put out - right?) for any length of time and isn't still doing the job they started with knows this implicitly. None of IT is about anything except the business - it's merely a means to an end, or a necessary evil depending on how good your IT organisation is.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
every company
every host
every every every
thing can be hacked!!!
isnt that what /. is all about?