SAIJE Thoughts

Or  Edgar Allen Poe Teaches Risk Management

 One of the comments on my Much Ado About Mapping  post asked the following question, “…thoughts about if following frameworks actually leads to the most effective security…  I wonder why infosec hasn’t applied some rigorous scientific methods for risk analysis and reduction.”

My thoughts:

Frameworks when applied like a check list, are relatively easy when compared to rigorous, scientific methods. In the

absence in many organizations of dedicated security professionals, the checklist approach may be a relatively simple approach to improve security, but as with my mapping example, there is a danger when blindly implemented. Specifically, do you know what you are protecting or are you just following instructions. There is a quote to the effect of “You cannot manage what you don’t know you have” Check lists can be good - pilots use checklists before operating a highly complex machine, but I hope that they know what each step means before implementing. So the key to a framework implementation that actually improves security involves:

1. Knowing your beginning and end states and

2. Understand the actions you are taking.

 Of course the cynic in me cites the lazy man approach - are you going to do what’s already been done by someone else or are you going to study what you need to know?

In addition, the ability of your average professional to implement “rigorous scientific methods” may be rather limited as that is not their field of expertise. I think to implement something like this you would need a seperate class of individual to quantify the risk for the security professional to implement. And you do hear terms such as CRO. The areas where risk is relatively well defined (banking, insurance, etc) have whole areas dedicated to risk and they do it well because otherwise large sums of money would be lost. In the security field, I don’t think that many companies fully understand the risk in those terms, like banks and insurance companies do, although I think that is changing to some extent. 

There are actually some impressive scientific methodologies out there and good examples of quantitative risk analysis. One interesting one I came across is the Algebraic Specification of Network Security Risk Management  provided you are  mathematical genius. I am not. A simpler, and so in my case, more interesting post is on the blog Technology Reflections.

 Another key problem is the wide variety of variables that one would need to fully provide a quantified risk analysis. Many of us are simply limited in our capacity to run simulations that run mutiple independent variables that would allow for some sort of discernible outcome. There is software out there to do the work, but one still needs to understand exactly what they are measuring. A practical method to run multiple variables over many iterations is called the Monte Carlo method and the link has a brief explanation including the math behind it, although I prefer to use an excel plug in.

There are some decent processes that anyone can use for risk analysis. A process is provided within NIST publication SP 800-30 and the draft 800-39 and in the issue of Control from the ISACA that I reviewed in my last post there was some decent discussion of risk. I think a hybrid approach where one does the best one can on a qualitative and quantitative risk assessment and then implements a set of controls likely works well enough.

So I guess my thoughts are:

• Frameworks are a good means to implement risk reductions schemes, but it may limit your actual understandings of the risks you are actually reducing and without some sort of analysis you may be implementing more (or less) than what you need, particularly as one shouldn’t spend more on risk reduction than the cost of the actual risk.

• We just haven’t acheived critical mass yet in terms of understanding the impacts of the risks yet, which would push for a more cohesive set of risk practices and professionals like we have in the insurance and banking industries.

• Apply a best effort risk analysis before implementing a given framework or set of controls.

• Give me a checklist.

Comments welcome.

With apologies to N.W.A’s Straight Outta Compton

 

The latest issue of Control came out. I have a hard time reading professional journals, although I know it’s in my best interest to do so, so I’m a skimmer. The contents of this specific issue can be found here: TOC. My main issue with most journals is that I prefer the “How to” type article or hard data. Often times you don’t get those. There are a few gems in this months journal that I think are worth reading and understanding. But first I found this rather humourous…

 The Article “Measuring the Readability of Sof tware Requirement Specifications” in the issue talks about how Specs are too hard to read and cover several tools that can help with readability and also provide other means to make them easier to read and understand. Two of the tools that are available in Microsoft Word are F.K. Readability and F.K Grade level. The authors stress that these tools should only be used as part of making specs readable but not the final determination of good quality specs and if used alone, the spec writer will likely still have a poor spec. In other words, they are a good tool to determine general direction and ‘Clues” to poor documentation but serious consideration needs to be made to have a more “holistic” tool avaialable to improve Specifications.  Quickly put, F.K Readability uses a score. The lower the score, the more difficult to read, with 30 or lower equating to college graduate level. F.K. Grade Level is a computation of the Grade Level. Out of curiousity, I cut and paste the article into word (realizing this is a Journal so I expected relatively difficult to read scores). Here is what I came up with.

I’m just saying…..

 OK - for the articles I LIKE….if you click on the link you will need an account with ISACA.org.

Practicing Information Technology Auditing for Fraud This is a good article (with a boring name) . One - lots of tables/pictures for simple guys like me.  Two, it really gives a good and simple methodology for determining Fraud risk and applying controls. Short, sweet and simple.

Is Your Printer Betraying Your Business?  Key items - networked printers have multiple services running on them that may be vulnerable to attack (IBM particularly had many services running), networked printers have admin accounts that would allow someone to redirect a copy of all documents by enabling fax forwarding - these accounts have default passwords that many don’t change. There are more intersting items here - I suggest reading this article.

Lastly Continuous Auditing Comes of Age is a good article looking to the future of Audit management . I found this interesting trying to put this in context of SAS70 audits. Continuous auditing means that data is constantly collected and audits then are incremental over time rather than massive efforts at certain points. This can reduce cost and find problems when they are small instead of later when the impact is cumulative. The article was directed at internal audit, I could see a significant benefit for external audits like SAS70 as well as the information/evidence should be much better and cleaner.

or Sexy as SOX on a Rooster

Not all companies need a SAS70 audit. There are several key reasons one would need a SAS70 audit.

• You are a company that provides outsourced services to public companies. Public companies, as a result of Sarbanes-Oxley, are required to show their service providers have appropriate controls over processes and technology. In this case, you most certainly need a SAS70 audit.
• You are a company that may want to provide outsourced services to public companies. In this case, you are anticipating a need.
• You are a company that wishes to differentiate yourself from other companies providing a similar service. In this case, you are using the SAS70 as part of your business development strategy.
• You are a company that for some reason or another may be audited by many of your customers, public or private. In this case a single SAS70 can eliminate the need for multiple audits, making your audit “life” much easier.
• You are a company that sees a need to improve your internal controls and verify that improvement. This really is more a side benefit to conducting a SAS70 audit.

These are the primary reasons one would need a SAS70 audit. I can’t think of any other good reasons, so if you don’t fall into one or more of the categories above, then you likely shouldn’t put the effort into a SAS70 audit. If you can think of another valid reason, feel free to comment.

In addition, you need to decide the type of SAS70 audit. In reality, the only useful SAS70 audit is a Type II audit. To me, the only reason for a Type I is in preparation for a Type II or as a stop gap measure when you know you may have problems passing a Type II and you want to reduce the scope rather than “fail” a SAS70. The primary difference is a Type I only verifies the controls at a specific point in time, while a Type II verifies that the controls are in place and operational over a significant period of time (min. 6 months).