Slashdot Mirror
Managing Information Security Risks
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.
Couldn't they pick an name that wasn't in use already?
GNU Octave is a high-level language, primarily intended for numerical computations.
Never ask for directions from a two-headed tourist! -Big Bird
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.
One man's Funny is another man's Offtopic.
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.
© 2004 The SCO Group, Inc. All Rights Reserved.
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.
Read my keyboard review.
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. 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.
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 to back you up. Additionally, if you have customers in California, then SB 1386 can be helpful. Although it does not directly say what controls to put in place, it requires companies to disclose to its customers security breaches.
Having said all of this, a real frustrating issue in the US is that there are NO laws that require a company to protect it's employees data! I know of a company that had private employee data available on an FTP server for all the world to see, and the employees had no say in the matter.
Enjoy
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.
FYI: HIPAA not HIPPA.
(Health Insurance Portability and Accountability Act)