Forgot your password?
typodupeerror

+ - Book review: Measuring and Managing Information Risk: A FAIR Approach

Submitted by benrothke
benrothke (2577567) writes "Measuring and Managing Information Risk: A FAIR Approach

Author: Jack Freund and Jack Jones

Pages: 408

Publisher: Butterworth-Heinemann

Rating: 10/10

Reviewer: Ben Rothke

ISBN: 978-0124078147

Summary: Superb overview to the powerful FAIR risk management methodology





It's hard to go a day without some sort of data about information security and risk. Researches from firms like Gartner are accepted without question; even though they can get their results from untrusted and unvetted sources.



The current panic around Ebola shows how people are ill-informed about risk. While distressing over Ebola, the media is oblivious to true public health threats like obesity, heart disease, drunk driving, diabetes, and the like.



When it comes to information security, is not that much better. With myriad statistics, surveys, data breach reports, cost of data breach: global analyses and the like, there is an overabundance of data, and an under abundance of meaningful data.



In Measuring and Managing Information Risk: A FAIR Approach, authors Jack Freund and Jack Jones have written a magnificent book that will change the way (for the better) you think about and deal with IT risk.



The book details the factor analysis of information risk(FAIR) methodology, which is a proven and credible framework for understanding, measuring, and analyzing information risk of any size or complexity.



An Open Group standard, FAIR is a methodology and a highly effective quantitative analysis tool.



The power of FAIR is immense: it enables the risk practitioner to make well-informed decisions based on meaningful measurements. While that seems obvious, in practicality, it is a challenging endeavor.



FAIR is invaluable in that it helps the risk professional understand the language that the corporate board and senior executives speak. Understanding that and communicating in their language can make it much easier for information security to be perceived as a valued asset, as opposed to using Chicken Little statistics.



FAIR takes the risk professional out of the realm of the dealing with risk via the checklist; which only serves to produce meaningless measurements, into the world of quantitative, defendable results.



For those that are looking for a tool to create pretty executive summary charts with lots of colors, FAIR will sorely disappoint them. For those that are looking for a method to understand how to calculate qualitative risk to support a formal enterprise risk management program, they won't find a better guide than this book.



The book is an incredibly good reference that will force you to look again at how you view risk management.



Jones writes in the preface that the book is not about checklists and formulas, but about critical thinking.



The authors note that information security and operational risk has operated for far too long as an art, with not enough science. This is the gap that FAIR attempts to fill.



The authors write that risk decision making quality boils down to the quality of information decision makers are operating from, and the decision makers themselves. The book does a remarkable job of showing how a person can become a much better decision maker.



A subtle but important point the book makes early on is that many risk professionals confuse risk possibilities with risk probabilities. The FAIR method forces you to focus on probabilities and not to obsess with Ebola like possibilities. Such a quantitative analysis approach is what makes FAIR so beneficial.



The book spends a few chapters on going through FAIR risk ontology and terminology. Inconsistent and poorly defined terminology is one of the most significant challenges the information security and operational risk profession faces. Having a consistent set of logical terms and definitions that make up the FAIR framework significantly improves the quality of risk relations communications within an organization.



The value of having a consistent set of logical terms and definitions is significant. For example, the book notes that many people use the term threat. In the context of risk analysis, it might not be a real threat if there is no resulting loss. In that case, it would be considered a vulnerability event.



The challenge of FAIR is acclimating to its dialect. But once done, it creates an extremely powerful methodology for risk communication and management. And therein lays its power. Setting up a common framework for risk management becomes and invaluable tool to present risk ideas. In addition, it makes the findings much more objective and defendable.



In chapter 5, the authors address the biggest objections to quantitative risk management that it can't be measured or is simply unknowable. They agree that risk can't be measured at the micro level, but it canbe effectively measured to the degree to reduce management's uncertainly about risk.



They also importantly note that risk is a forward-looking statement about what may or come to pass in the future. With that, perfect accuracy is impossible; but effective quantitative risk management is very possible.



The power of FAIR is that is helps add clarity to ambiguous risk situations by giving you the tools to add data points to a situation that is purported to be unknowable.



Chapter 8 is an extremely enlightening chapter in that it provides 11 risk analysis examples. The examples do a great job of reinforcing the key FAIR concepts and methods.



In chapter 10, the authors write that the hardest part of learning FAIR is having to overcome bad habits. For most people, FAIR represents a recalibration of your mental model about what risk is and how it works. The chapter deals with common mistakes and stumbling blocks when performing a FAIR analysis. The 5 high-level categories of mistakes the chapter notes are: checking results, scoping, data, variable confusion and vulnerability analysis.



FAIR is a powerful methodology that can revolutionize risk management. The challenge is that it takes a village to make such a change. Management may be reticent to invest in what is perceived as yet another risk management framework.



But once you start using the language of FAIR and validate your findings, astute management will likely catch on. Over time, FAIR can indeed be a risk management game changer.



The book is flawless in its execution and description of the subject. The only critique is that in that the author's should have been a bit more transparent in the text when (especially in chapter 8) mentioning the FAIR software, in that it is their firm that makes the software.



For those that are willing to put in the time to understanding FAIR, this book it will make their jobs much easier. It will help them earn the trust of senior management, and make them much better risk management professionals in the process.







Reviewed by Ben Rothke"

Comment: Re:The cloud (Score 1) 75

by benrothke (#47858073) Attached to: Book Review: Architecting the Cloud

::::First and foremost, the cloud is not in any way shape or form secure.Any thing you put there is there to share.

It’s as secure as you want to make it.

Many firms that take security seriously use the cloud. :::::Second, it is a buzzword that is used to get gullible suits to think that they can get rid of their IT depatments.

You do have a good point there.

Comment: Re:More details please... (Score 1) 75

by benrothke (#47858039) Attached to: Book Review: Architecting the Cloud

:::::Will an experienced admin (20+ years *NIX) that's currently using RackSpace (dedicated and cloud) learn anything from this book? It's so hard to tell from this review.

I think so. :::I've been using RackSpace for a few months now and I find that it's not much different than hosting the servers myself except I don't have to deal with things like router/switch configuration and hardware replacements.

From a hosting and sys admin perspective, it is not a radical difference.

But from a cloud application perspective, there is a lot to learn.

Comment: Re:a solution in search of a problem (Score 1) 75

by benrothke (#47857947) Attached to: Book Review: Architecting the Cloud

:::entrust their data to some unknown and unmonitored external entity such as the 'cloud'.

Do you really consider Amazon Web Services unknown and unmonitored?

The granularity of what they can report on shows their monitoring capabilities are quite sophisticated. :::Until that time, safe and productive cloud computing is just a fantasy. It's a solution in search of problem. Avoid it.

I think the facts speak for themselves. There are thousands of examples of safe and productive instances of cloud computing,

But there are also tens of thousands of examples of insecure and unproductive instances of cloud computing,

Comment: Re:Sounds like a good read (Score 1) 75

by benrothke (#47857925) Attached to: Book Review: Architecting the Cloud

The book doesn’t deal with acceptable use per se, as much of acceptable use is determined by the specific user of the cloud.

As I wrote about “almost any security regulation or standard can be met in the cloud. As none of the regulations and standard dictates where the data must specifically reside”.

So if you define what the with acceptable use is and build that into your cloud policy and contract, that would be acceptable.

Comment: Re:One simple question I wish were answered... (Score 1) 75

by benrothke (#47857899) Attached to: Book Review: Architecting the Cloud

That’s a major question and one that every firm needs to address before using the cloud.

There are safeguards you can put in place. You can back-up all cloud data as a start.

There are a lot of articles on the topic. Check this one out as a start: http://spendmatters.com/2013/1...

Comment: Re: "Architecting" ??? wtf...? (Score 1) 75

by benrothke (#47857877) Attached to: Book Review: Architecting the Cloud

A search of www.merriam-webster.com returns: the word you've entered isn't in the dictionary. So you are correct, this is not an official English word.

But its de facto use is seen at:
http://gapp.usc.edu/graduate-p...
http://aws.amazon.com/training...
http://www.cs.berkeley.edu/~al...

Lookif selfie can be a word, why can’t we let architecting in?

+ - Book review: Architecting the Cloud

Submitted by benrothke
benrothke (2577567) writes "Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS

Author: Michael Kavis

Pages: 224

Publisher: Wiley

Rating: 9/10

Reviewer: Ben Rothke

ISBN: 978-1118617618

Summary: Extremely honest and enlightening book on how to effectively use the cloud





Most books about cloud computing are either extremely high-level quasi-marketing tomes about the myriad benefits of the cloud without any understanding of how to practically implement the technology under discussion. The other type of cloud books are highly technical references guides, that provide technical details, but for a limited audience.



In Architecting the Cloud: Design Decisions for Cloud Computing Service Models, author Michael Kavis has written perhaps the most honest book about the cloud. Make no doubt about it; Kavis is a huge fan of the cloud. But more importantly, he knows what the limits of the cloud are, and how cloud computing is not a panacea. That type of candor makes this book an invaluable guide to anyone looking to understand how to effective deploy cloud technologies.



The book is an excellent balance of the almost boundless potential of cloud computing, mixed with a high amount of caution that the potential of the cloud can only be manifest with effective requirements and formal security architecture.



The full title of the book is: Architecting the Cloud: Design Decisions for Cloud Computing Service Models: SaaS, PaaS, and IaaS. One of the mistakes of using the cloud is that far too many decision makers rush in, without understanding the significant differences (and they are significant) between the 3 main cloud service models.



The book crams a lot in under 200 pages in the following 16 chapters:

1 Why Cloud, Why Now?

2 Cloud Service Models

3 Cloud Computing Worst Practices

4 It Starts with Architecture

5 Choosing the Right Cloud Service Model

6 The Key to the Cloud: RESTful Services

7 Auditing in the Cloud

8 Data Considerations in the Cloud

9 Security Design in the Cloud

10 Creating a Centralized Logging Strategy

11 SLA Management

12 Monitoring Strategies

13 Disaster Recovery Planning

14 Leveraging a DevOps Culture to Deliver Software Faster and More Reliably

15 Assessing the Organizational Impact of the Cloud Model

16 Final Thoughts



In chapter 1, he provides a number of enthusiastic cloud success stories to set the stage. He shows how a firm was able to build a solution entirely on the public cloud with a limited budget. He also showcases Netflix, whose infrastructure is built on Amazon Web Services (AWS).



Chapter 3 is titled cloud computing worst practicesand the book would be worth purchasing for this chapter alone. The author has a number of cloud horror stories and shows the reader how they can avoid failure when moving to the cloud. While many cloud success stories showcase applications developed specifically for the cloud, the chapter details the significant challenges of migrating existing and legacy applications to the cloud. Such migrations are not easy endeavors, which he makes very clear.



In the chapter, Kavis details one of the biggest misguided perceptions of cloud computing, in that it will greatly reduce the cost of doing business. That is true for some cloud initiatives, but definitely not all, as some cloud marketing people may have you believe.



Perhaps the most important message of the chapter is that not every problem is one that needs to be solved by cloud computing. He cites a few examples where not going with a cloud solution was actually cheaper in the long run.



The book does a very good job of delineating the differences between the various types of cloud architectures and service models. He notes that one reason for leveraging IaaS over PaaS, is that when a PaaS provider has an outage, the customer can only wait for the provider to fix the issue and get the services back online. With IaaS, the customer can architect for failure and build redundant services across multiple physical or virtual data centers.



For many CIO's, the security fears of the cloud means that they will immediately write-off any consideration of cloud computing. In chapter 9, the author notes that almost any security regulation or standard can be met in the cloud. As none of the regulations and standard dictate where the data must specifically reside.



The book notes that for security to work in the cloud, firm's needs to apply 3 key strategies for managing security in cloud-based applications, namely centralization, standardization and automation.



In chapter 10, the book deals with creating a centralized logging strategy. Given that logging is a critical component of any cloud-based application; logging is one of the areas that many firms don't adequate address in their move to the cloud. The book provides a number of approaches to use to create an effective logging strategy.



The only issue I have with the book is that while the author is a big fan of Representational state transfer (REST), many firms have struggled to obtain the benefits he describes. RESTful is an abstraction of the architecture of the web; namely an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.



I think the author places too much reliance on RESTful web services and doesn't detail the challenges in making it work properly.RESTful is not always the right choice even though it is all the rage in some cloud design circle.



While the book is part of the Wiley CIO Series, cloud architects, software and security engineers, technical managers and anyone with an interest in the cloud will find this an extremely valuable resource.



Ironically, for those that are looking for ammunition why the cloud is a terrible idea, they will find plenty of evidence for it in the book. But the reasons are predominantly that those that have failed in the cloud, didn't know why they were there in the first place, or were clueless on how to use the cloud.



For those that want to do the cloud right, the book provides a vendor neutral approach and gives the reader an extremely strong foundation on which to build their cloud architecture.



The book lists the key challenges that you will face in the migration to the cloud, and details how most of those challenges can be overcome. The author is sincere when he notes areas where the cloud won't work.



For those that want an effective roadmap to get to the cloud, and one that provides essential information on the topic, Architecting the Cloud: Design Decisions for Cloud Computing Service Modelsis a book that will certainly meet their needs.





Reviewed by Ben Rothke"

+ - Book review: Social Engineering in IT Security Tools, Tactics, and Techniques

Submitted by benrothke
benrothke (2577567) writes "Title: Social Engineering in IT Security Tools, Tactics, and Techniques

Author: Sharon Conheady

Pages: 272

Publisher: McGraw-Hill Osborne Media

Rating: 8/10

Reviewer: Ben Rothke

ISBN: 978-0071818469

Summary: Great resource on which to build a social engineering testing program



When I got a copy of Social Engineering in IT Security Tools, Tactics, and Techniquesby Sharon Conheady, my first thought was that it likely could not have much that Christopher Hadnagy didn't already detail in the definitive text on the topic: Social Engineering: The Art of Human Hacking. Obviously Hadnagy thought differently, as he wrote the forward to the book; which he found to be a valuable resource.



While there is overlap between the two books; Hadnagy's book takes a somewhat more aggressive tool-based approach, while Conheady take a somewhat more passive, purely social approach to the topic. There are many more software tools in Hadnagy; while Conheady doesn't reference software tools until nearly half-way through the book.



This book provides an extensive introduction to the topic and details how social engineering has evolved through the centuries. Conheady writes how the overall tactics and goals have stayed the same; while the tools and techniques have been modified to suit the times.



The following are the chapters in the book:



1. Social Engineerings Evolution

2. The Ethical and Legal Aspects of Social Engineering

3. Practical Social Engineering and Why it Works

4. Planning Your Social Engineering Test

5. Reconnaissance & Information Gathering

6. Scenario Creation & Testing

7. Executing Your Social Engineering Test

8. Reporting

9. The Social Engineering Arsenal & Tools of the Trade

10. Defense Against Social Engineering Attacks

11. Tomorrows Social Engineering Attacks



Coming in at about 250 pages, the book finds a good balance between high-level details and actionable tactical things to execute on. Without getting bogged down in filler.



Since the social engineering tools and techniques only get better, the advantage Conheady's book has it that it details a lot that has changed in the 4 years since Hadnagy's book came out.



In chapter 1, she writes about mumble attacks, which are telephone-based social engineering attacks that are targeted at call center agents. The social engineer will pose as a speech-impaired customer or as a person calling on behalf of the speech-impaired customer. The goal of this method is to make the victims; in this case call center agents feel awkward or embarrassed and release the desired information. Given the pressure in which most call center agents are under; this is a simple yet highly effective attack.



Like Hadnagy, this also has a detailed social engineering test methodology. Conheady details a methodology with 5 stages: planning and target identification, research and reconnaissance, scenario creation, attack execution and exit, and reporting. She notes that one does not have to be a slave to the methodology, and it can be modified depending on the project.



Social engineering can often operate on the limit of what is legal and ethical. The author goes to great lengths to write what the ethical and legal obligations are for the tester.



The book is filled with lots of practical advice as Conheady is seasoned and experienced in the topic. From advice to dealing with bathrooms as a holding location, gaining laptop connectivity and more; she writes of the many small details that can make the difference between a successful social engineering test and a failed one.



The book also details many areas where the job of the social engineer is made easy based on poor security practices at the location. Chapter 7 details how many locations have access codes on doors often don't do much to keep social engineers out. Many doors have 4-character codes, and she writes that she has seen keypads where the combination numbers have been so worn down that you can spot them straightaway.



As noted earlier, the book focuses more on the human techniques of social engineering than on software tools. She does not ignore that tools and in chapter 9 provides a list of some of the more popular tools to use, including Maltego, Cree.py and others. She also has lists of other tools to use such as recording devices, bugging devices, phone tools and more.



With all those, she still notes that the cell phone is the single most useful item you can bring with you on a social engineering test. She writes that some of the many uses a cell phone has is to discourage challengers, fake a call to look busy, use the camera and more.



While most of the book is about how to execute a social engineering test, chapter 10 details how you can defend against social engineering. She notes that it is notoriously difficult to defend against social engineering because it targets the weakest link in the security chain: the end-user. She astutely notes that a firm can't simply roll out a patch and immunize its staff against the latest social engineering attack. Even though there are vendors who make it seem like you can.



The chapter also lists a number of indicators that a firm may be experiencing a social engineering attack.



Hadnagy's book is still the gold-standard on the topic. But Social Engineering in IT Security Tools, Tactics, and Techniquescertainly will give it a run for the money.



Hadnagy's approach to social engineering is quite broad and aggressive. Conheady takes more of a kinder, gentler approach to the topic.



For those that are looking for an effective guide on which to build their social engineering testing program on, this certainly provides all of the core areas and nearly everything they need to know about the fundamentals of the topic.







Reviewed by Ben Rothke"

To err is human -- to blame it on a computer is even more so.

Working...