Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Books Media Book Reviews

Managing Information Security Risks 67

nazarijo (Jose Nazario) writes "With regulatory compliance hanging over so many peoples' heads (GLBA, SOX, HIPAA, etc), information security and related fields have taken on a new twist in recent years. To that end, a number of people are looking at formal evaluation methods like OCTAVE to help guide them through the tricky world of audits. It's a sensible move, too, because you want something documented, thorough, and demonstrable when it comes to an audit, and preferably something objective. The book Managing Information Security Risks: The OCTAVE Approach by Christopher Alberts and Audrey Dorofee is intended to help you fill this need." Read on for the rest of Nazario's review.
Managing Information Security Risks: The OCTAVE Approach
author Christopher Alberts and Audrey Dorofee.
pages 471
publisher Addison-Wesley Longman
rating 5
reviewer Jose Nazario
ISBN 0321118863
summary An introduction to information security risk management using the OCTAVE method

Authors Alberts and Dorofee are the principal developers of OCTAVE and are staff members at the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU), where CERT has offices. As such, they're the right people to describe OCTAVE. The CERT OCTAVE website area explains the process in more detail. Needless to say, OCTAVE is a very large, complex, heavy process for an organization to go through, with some arguable benefits. Very few organizations have done so to the best of my knowledge -- most of them are scared off by the complexity of the whole undertaking.

This brings up a very important point. It's important to state the difference between a critique of the OCTAVE method and the book itself. OCTAVE is interesting in that it's an attempt to formalize the complex process of information security evaluations. Despite its shortcomings and turnoffs, it has a purpose, and I wont dispute it for the most part. The book, instead, covers an abbreviated format of OCTAVE. It's important to focus on the strengths and weaknesses of the book and not the topic.

The books is organized into three main parts. Part 1 (covering chapters 1 and 2) is an introduction to the principles being discussed in the book. The method itself, and therefore these chapters, focus on a formal evaluation of information security risks and how to manage them. The principles focus on enumeration of assets, their threats and vulnerabilities, and then remediation of the threats to minimize the risk. The section introduces the core concepts to this philosophy.

Part 2 of the book, covering chapters 3 through 11, server two main purposes, preparation and then execution of the method. Chapter 3 introduces the fundamentals of the OCTAVE method, specifically how the three phases (asset-based threat profiles, vulnerability identification, and security strategy planning) fit together. The inputs of the method and its outputs are then described; you'll be using them in later chapters. Chapter 4 helps you prepare for the approach in your organization, including how important it is to get management buy-in, who will participate, and how to organize the evaluation. Project managers will adore this chapter.

The next few chapters cover the meat of the OCTAVE method. Chapter 5 covers processes 1 to 3, where assets are enumerated and the current state of the security profile is captured, as well. This step is crucial for building a baseline and knowing what you'll have to cover. Chapter 6 leads you through the threat profile, where you examine assets that you've identified as critical and the security requirements for them. And finally, in Chapter 7, the basic identification steps are done as you identify critical infrastructure components to examine later on. This is done so that you can work efficiently, as opposed to studying every asset in depth. By studying classes of assets you can (hopefully) achieve the same coverage without spending valuable time repeating the process.

Chapters 8 and 9 deal with the commonly understood parts, the actual vulnerability and risk analysis. Chapter 8 discusses vulnerability assessment tools and some basic questions to ask about them, but leaves the actual evaluation of those tools up to another text. Chapter 9 then helps you undertake the actual risk analysis, such as the impact of any threat being realized or the probability that one would be encountered. This is what most people think of when they think of an information security audit.

This gets to what is perhaps my biggest complaint about the book. It doesn't teach you how to think creatively about threats to information security. Instead, you're told to enumerate assets and threats against them via brainstorming, as though you'll somehow "get it" the first time (or every time). For someone new to the field, this can be hard, because not all assets are obvious -- and not all threats are understood. It's a hard skillset to teach, but it should have been attempted with more gusto.

Chapters 10 and 11 close the big circle of an information security audit, by developing an information security protection strategy. It's basically a series of outlines of meetings and their agendas as you present the findings of the evaluation but are (obviously) vague in the absence of any concrete findings.

This is probably a good time to raise another objection to this book. My second biggest complaint is that the authors never cut to the heart of what the OCTAVE method is trying to do. Sure, the book covers a stripped-down version of OCTAVE, but it doesn't ever get at how you can really adapt this to your organization. Instead, it's a series of rigid steps in the OCTAVE method. If you attempt to do something different for whatever reason, you're on your own. Again, an attempt to work in some flexibility beyond what is present in Chapter 12 (An Introduction to Tailoring OCTAVE, the start of part 3) would have been welcome. This chapter just keeps you inside the narrow confines of the OCTAVE approach.

Chapter 13 attempts to bring this home by discussing the practical applications for an organization. They attempt to discuss how a small company would utilize OCTAVE, but to be honest it's so heavy and time-consuming it's hard to see how they would employ anything but the barest of concepts to their workflow. Three other examples are given: a very large distributed organization, an integrated Web portal service provider (which faces unique threats), and large and small organizations. Again, while this chapter attempts to show how to tailor OCTAVE to anything but the largest and most diligently staffed of organizations, it falls to get to the salient points of the method. Instead, it tries to foist the process on them.

Finally, chapter 14 tries to bring it all home and discuss the information security life cycle of analysis, monitoring, control, and implementation (not in that order). They hope that OCTAVE has become a part of this process and show how it complements and matures this process. Instead, I wonder if an organization will think about the effort they just expended and be reluctant to do this again. The appendices are piles of worksheets, charts and workflows to go through with OCTAVE. You can make photocopies and use them if you implement the OCTAVE approach. It's very hard to take consider these methods strong enough when you read about the report card government agencies received for information security. While they may have not been following OCTAVE, it's hard to see how a book that so superficially treats the subject matter can help anyone do better. Almost everything is just a high-level line-item risk-and-mitigation strategy. Things like "Our organization cannot deliver effective or efficient health care without PIDS" and an impact of "High" are, to put it mildly, interesting in their superficiality. So many things are simply glossed over, yet so many worksheets remain. On the other hand, if a fair treatment of threats, assets, and the like were fully discussed the book would be many more volumes, a significantly more tedious tome, and too sensitive to the shifting sands of time.

Overall the book does a decent job of covering OCTAVE's core premises, but doesn't really provide much beyond that. It's a complex process that doesn't work well for a number of organizations. Instead of helping organizations see how to use it, the authors simply keep presenting OCTAVE for what it is, which makes me question the value of this book beyond someone who has already decided to implement OCTAVE. It doesn't seem like it has a lot to offer anyone who doesn't have a large body of knowledge in information security management and a staff to deploy with worksheets in hand. The book simply fails to contribute greatly beyond the very narrow specifics of OCTAVE.


You can purchase Managing Information Security Risks: The OCTAVE Approach 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.

Managing Information Security Risks

Comments Filter:
  • by Rosco P. Coltrane ( 209368 ) on Monday February 21, 2005 @05:35PM (#11739249)
    From TFA:

    the authors simply keep presenting OCTAVE for what it is, which makes me question the value of this book beyond someone who has already decided to implement OCTAVE

    Title of the book:

    Managing Information Security Risks: The OCTAVE Approach

    So, like, duh...
    • I get the feeling that part of the problem here wasn't that the book didn't cover the bare minimum of what the title implied it would cover, but that it had little value above that which is already available as PDFs [cert.org]. From what I could tell, the reviewer was hoping for a more in-depth discussion of OCTAVE and security threats - something more interesting and meaty that would make it worth paying sixty American ducats for it.
  • by Sheetrock ( 152993 ) on Monday February 21, 2005 @05:36PM (#11739259) Homepage Journal
    People having access to information that should not.

    Strictly partitioning information access on a organizational basis costs money and increases friction within an organization, which is traditionally (in addition to a certain lesser-faire attitude towards other people's information) why such measures have been opposed. The pressure to outsource and a greater degree of connectivity has only increased this risk.

    The problems would clear up overnight if the companies involved had a greater degree of legal liability for their actions. Look at HIPA.

    • This is what Sarbox and it's European counterpart bring to the table: a higher dgree of legal liability for corporate officers.
    • 100% of information theft can be summed up thusly:

      DON'T GET CAUGHT
    • by bluGill ( 862 ) on Monday February 21, 2005 @06:09PM (#11739486)

      I'm hired and paid to make the company money.

      Read that again.

      Now my talents are in computer programing, and it is a waste of everyone's time if I spend more than a few moments balancing my companies accounts. An accountant can do that better and faster. However it is also a waste for me to call an accountant when I need a USB cable or some such. It is a better use of everyone's time if I just order the cable and enter it into the books. (Best Buy is just around the corner, I can be back before the purchasing guy reads my request) The accountant will check the math latter, but the data is there.

      However to give me that ability means the books need to be open to me. I should not have access to accounting data, but it is easier for everyone if I have full access.

      Even in the small 10 person company I work for I don't get to know how much money my co-workers make. It means that the books are closed, so I can't enter my USB cable myself, I have to get someone else to enter it. (and in fact someone else ends up buying it)

      Don't forget the other big downside. If the company officers are keeping two sets of books I don't know that. Therefore I can't blow the whistle on them. (If there is fraud and you are an officer in the company this is good, to the investors which might include my retirement account this is bad) I also have no clue if my stock options (I wish...) that seem high today will pull and Enron before they vest.

      • If there is fraud in the company and no one notices then that is not good for the officers. Sarbanes-Oxley now holds officers *directly responsible* for the accuracy of the books. So if the company is private they might pull it off. If public they == screwed.
      • Nobody cares.

        Read that agian.

        Regulators, auditors are not concerned with real risk. What they want is a stack of documentation they can point to as an example of how they are doing what they need to do.

        Senior Mgmt only cares that the regulators and auditors are happy. Who cares if it's dragging the company under.

        I'm working under CFR 21 Part 11. This piece of crap does nothing to protect my company. The things it asks for are basic IT functions wrapped up in a layer of paperwork. It costs my compan
      • So buy/build/whatever an accounting program that modularizes data access, i.e. you have access to enter your own purchases but not to look up salaries.

        I routinely work with MAS 90; for a basic system such as you describe, I think it would run you a one-time cost in the low five digits, plus a small percentage of that amount annually for updates and support. There may be cheaper programs that also offer modular data access (though I don't know any off the top of my head, and they probably have less feature
      • Petty Cash [answers.com].

        Do U.S. companies not do this? Have £50 or so in small notes and change locked in a drawer somewhere, you swap the receipt for your doodad with money from the petty cash box. Maybe you sign a paper ledger and someone types that in whenever they're sorting the accounts out. Seems like a better system than letting people potentially mess your whole company's payroll up by accident. In fact, I'd much rather keep vital stuff like accounts on a computer not connected to the network at all, not

      • And I use them all the time for buying doohickies under $100 or so. Everything else requires a purchase request in order to maintain a documented chain of purchasing authority and to deliberately slow the process down so that one can consider "Is This Thing Really Necessary?".

        I set up my company that way, and I'm bound by it myself.

        And it works really, really, really well.
  • by PornMaster ( 749461 ) on Monday February 21, 2005 @05:39PM (#11739285) Homepage
    Does Sarbanes-Oxley cover security at all? I was under the impression that it didn't.
    • Only in the sense that companies must retain their relevant documents for 7 years -- you don't want to destroy something accidentally. Other laws (FACTA, GLB, HIPAA) are more security-focused, though.
    • by neilb78 ( 557698 ) on Monday February 21, 2005 @05:47PM (#11739340)
      Yes, absolutely! It requires that proper security controls are in place and that there are checks and balances. SOX auditors will look for users that have more authority than they should as well as many other security related items.
    • Section 404 talks about protecting the "integrity" of financial data.

      Read from that what you will.
    • ...thinking they were talking about the sound file translation package. :) Arguably, there are no approaches (other than formal methods, coupled with formal proofs) that can really be argued to be about security. They are generally only about a very narrow, specific aspect of security.
      • Well, sure, but there can be huge penalties associated with breaches due to insufficient security procedures, like for companies like ChoicePoint which were neglectful.
        • Oh, that's undoubtably true. Only, in the case of ChoicePoint, I suspect the company will suffer very little. It'll be the people who trusted them who will pay the real price.

          I would break down security into several layers. First, there's an "outer layer", which covers authentication, validation, encryption, etc. Basically, is the person/computer/process connecting who they say they are? Are the incoming packets really from them, not forged or modified in transit? Is it possible to intercept enough inform

          • Good post.

            There is one thing missing from your security model. Most exploits come from people who are allowed access to information who misuse it. So the fact that you have a (in your parlance) a 5/5/5 system is neither here nor there - the compenents in the system performed in the correct and secure manner, but the user is the rogue component.

            The missing thing, of course, is auditing - not only failures (sort of goes without saying) but successes. You should be able to take, say, a file, and produce a h
    • Strictly speaking, SOX has no Information Security requirements outside of being able to ensure the integrity of the financial information. This piece of legislation is almost useless for anyone who wishes to have their company implement appropriate controls on their network and data.

      In the financial world, you *may* have better luck with GLB. However, GLB leaves a great deal to interpretation when it comes to requiring *appropriate* controls.

      If you can make a tie in with HIPPA, then you have a bit more t
    • Strictly speaking, no. But the law requires that higher-ups in the company be able to sign off on everything from the accounting ledger to documents filed with the SEC (which, especially in the banking world, is a *lot* of paperwork).
      What this amounts to is that, especially in a large company with a lot of employees, people want very fine grained access controls on everything with detailed audit logs fo a minimum of 7 years. Enter IT...
      To get an idea of the minutia involved, imagine having to make it so t
  • a few thoughts (Score:5, Insightful)

    by outcast36 ( 696132 ) on Monday February 21, 2005 @05:42PM (#11739303) Homepage
    As someone who has experience with OCTAVE, let me say this reviewer is right on with his notes.... however, this process is for bigwigs and government offices sooo....
    1. Of course there is a lot of paperwork. What good is a framework for govt use if it doesn't document everything in triplicate.
    2. Regarding sitting around enumerating threats and assets, you are correct, the more tech-savvy among us are better able to think more creatively about threats.
      However, if I was paying for security (like all stakeholders are), that is not what is important. The assets are what is important. I was involved in this process for a major hospital chain. Of course, we wanted to scan networks and probe for vulns (we did), but it was interesting hearing the "lusers" talk about the voice system. Having the other non-technical types helps you really understand which assets do the day-to-day work, and which assets were developed to put on someone's resume.

    3. In conlcusion, you are correct that a lot of the OCTAVE methodology is aimed at generating paperwork. However, I suggest you strip it down to Threat-Asset-Vulnerability (the TAV in OC-TAV-E) and run with that for a while.
    • However, I suggest you strip it down to Threat-Asset-Vulnerability (the TAV in OC-TAV-E) and run with that for a while.

      The "OC" doesn't *really* stand for Obsessive-Compulsive, you know.
  • Looks like a review of the table of contents, not the book.
  • Couldn't they pick an name that wasn't in use already?

    GNU Octave [octave.org] is a high-level language, primarily intended for numerical computations.
  • by Alexander ( 8916 ) on Monday February 21, 2005 @05:47PM (#11739342) Homepage


    One thing this book doesn't do a good job of is explaining the deficiencies in current risk assessment methodologies, be it OCTAVE, NIST, whatever....

    the numerical data presented is crap.

    Too many times some CISSP (either inhouse or outsourced) who sees possibility and confuses it with probability sticks his finger in the air and delcares that there's "high" risk today. There's no common taxonomy amoung Infosec professionals, there's no common rating system, and there's not enough data to drive probability analysis.

    Subsequently, run off with your Risk Assessment data to line of business management outside of IT, and they're laughing at infosec - and the credit card processing system remains a Tandem machine, the assembly line remains on the same segment as the rest of the network and the contingency plans remain "pen and paper".

    Don't get me wrong, the methodology in OCTAVE (and this book) are fine. Great places to start. But Infosec itself will remain in its infancy until there's a probabilistic means to express risk outside of IT.

    So in the meantime, you can run and do OCTAVE or NSA/NIST all you want, your CFO is still going to rely on the morons in the PWC/E&Y/DT&T infosec practice because they have some percieved authority to express risk (and they're getting their quantification the same place you are, from their behinds).

    • Oh, and NSA/NIST is a better methodology, anyway.
    • by Anonymous Coward
      "probabilistic means to express risk outside of IT"

      What part of "If you use IE and allow Internet access your Windows PCS you're gonnae get infected with all kinds of crap and reduce the value of what you've paid for down to crap" don't they understand? 100% probabilty. That's as quantitative as it gets.
    • I agree. Probability can be used only when there is enough historical data that you can use, as long as the system and the conditions don't change. As data is NEVER collected about how frequent or serious or costly are incidents, there's absolutly nothing you can use to do any real risk calculus.

      Furthermore, the system (IT) and the conditions (threat scenario) do change.

      Most consultants just cook the numbers to get the results managers want from them.

      I usually say that mixing estimating figures with math
      • As data is NEVER collected about how frequent or serious or costly are incidents, there's absolutly nothing you can use to do any real risk calculus.

        That's what Operational Risk systems do. Basel II (the 'capital accord' for financial organizations, a much more comprehensive SOX, if you like), expects three years data collection from which you can start to make quantatitive risk assessments. Basel II kicks in end of 2006 (by which time, you are supposed to have already collected 3 years data if I remem
  • It's really too bad that there's such a big messy system needed....

    It seems like there should be something with less red tape that gets the job done... any suggestions ?

  • Tough Problem (Score:5, Informative)

    by SlipJig ( 184130 ) on Monday February 21, 2005 @05:49PM (#11739355) Homepage
    I recently finished work on a "validated" application for a company regulated by the FDA. The validation process (which includes 21 CFR Part 11, covering electronic security) is intended to ensure that the software, as installed, meets the requirements and performs as expected. It tries to do this by requiring documentation of what are considered steps in good development methodology: requirements gathering, design elements, test cases, etc. It also covers things like installation - you have to take screen shots of the install process and show that they match what's in the install guide. The goal is provide traceability - that the design elements address the requirements, that the test cases cover the design, that the test cases were run and passed, and that the application was installed and configured correctly. I would imagine that the OCTAVE approach is similar, but focused on security.

    You can argue whether these things actually improve or get in the way of effective software development. I found the process time-consuming and fairly tedious, but it did force me to do things I might rationalize away otherwise... so I did a better job. Even so, I think gaining the desired level of certainty about a complex application requires an end-to-end effort to achieve, and that it's a difficult task under the best of circumstances.
  • by NZheretic ( 23872 ) on Monday February 21, 2005 @05:55PM (#11739401) Homepage Journal
    To quote Dr. Blaine Burnham, the former director of the Georgia Tech Information Security Center (GTISC) and previously with the National Security Agency (NSA), "Security is a system wide property". That requires applications, middleware, libraries and the operating system itself to be secured before the whole system can be declared secure.( If you have a spare hour, listen to Dr. Blaine's USENIX 2000 keynote [tinyurl.com] )

    Microsoft's desktop security issues stem from its continued reliance on the Antivirus industries "Infect-Scan-Remove" approach. Even Garner analyst Neil MacDonald has finally realized [com.com] "Microsoft's overriding goal should be to eliminate the need for (antivirus) and (anti-spyware) products, not simply to enter the market with look-alike products at lower prices,". In comparison, right from the outset, open source desktop platforms and applications have relied almost wholly on closing the infectable vectors, the exploited vulnerabilities used by malware, as quickly as possible. The result is that both the KDE and GNOME desktop environments are a lot more secure and even more secureABLE [slashdot.org].

  • by PIPBoy3000 ( 619296 ) on Monday February 21, 2005 @07:17PM (#11739986)
    I work in healthcare and the HIPPA rules are just starting to come into effect. The vast majority of the rules are fairly common sense, though sometimes the legal and operational implications are complex.

    For example, one of the tenants is that people have access to only what they need to do their job. While it sounds easy to manage, there's huge issues with tracking temps, contractors, and people shifting job responsibilities when tens of thousands of people have access to your systems.

    Then there's the auditing piece, making sure that people are using their security appropriately. I'm in the process of building a database that pulls in the 2 million records each day of people looking at patient information. Another group of people audit the information, making sure that people aren't looking up coworkers, friends, or family inappropriately.

    We're also drafting new policies that cover everything from sending patient information in e-mail (only if encrypted) to protecting physical access to computers, backups, PDA's and so on.

    Basically, it's a lot of work but it's been effective getting people thinking more seriously about these issues.
    • by Anonymous Coward
      You mean HIPAA, right? And I think that you mean "tenet", rather than "tenant" - unless you have people renting rooms.

      If you're only building the database now, I think you're behind. IIRC, there's an April deadline.
    • by BaldGhoti ( 265981 ) on Monday February 21, 2005 @08:04PM (#11740305) Homepage
      The nice thing about HIPAA is that we finally have a beating stick to use when we want to increase network security. The deans at our college don't give a rip if we have a compromised workstation, but once it goes from "compromised workstation" to "HIPAA violation" they pay a lot more attention.
      • sad but true; same thing at my uni. it's always "too expensive and bothersome" to implement things that would mitigate compromises and/or attacks until something really bad happens and the network is visibly affected. Then it's "why wasn't this fixed or avoided?".
    • by Anonymous Coward
      FYI: HIPAA not HIPPA.
      (Health Insurance Portability and Accountability Act)

  • For those recently fired at t-mobile.com.

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...