SAIJE Thoughts

Or “Minding the GAP(s)”

One of the items I notice a good deal is the extensive use of spreadsheets with Security Frameworks or Controls sets. The sad part is that there are so many tools out there that can better provide an overview of how well your organization is committed to Information Assurance and implementation of controls.In this post I am using Rational Requisite Pro and the NIST SP 800-53 as an example as I am a fan of the Open Unified Process (and Rational Unified Process by extension), but I am sure this method will work with any robust requirements management tool and framework/control set should you be willing to do the upfront work (or contract someone else to do it).

Within Requisite Pro, you have the means to track various types of requirements (such as Enterprise Requirements, Features and Supplemental Requirements). In my example, I use the NIST SP 800-53rev2 as a set of Enterprise Requirements. In other words, these requirements are applicable to all implemented projects in your organization. The document (or database should you use the database version of the NIST) is not in the proper format for importing into a Requirements Management Tool, so you need to either convert it into the proper format or find someone that may be doing the work for you already. In this case, I converted the NIST to a CSV table with the following key fields:

• Name – Name of the Control for Requisite Pro – eg. AC-2 : ACCOUNT MANAGEMENT
• Requirement Text – The text of the individual control – eg. The organization manages information system accounts, including establishing, activating, modifying, reviewing, disabling, and removing accountsThe organization reviews information system accounts [Assignment: organization-defined frequency, at least annually].
• Other fields – other fields that your Req. Management system uses are populated as well. I use Guidance extensively to add in all the supplemental information in the NIST Controls.

Each Control and Supplemental Control is listed as a discrete requirement.

Once populated, you now have a powerful means to implement controls, track projects, and even highlight projects that have gaps in their implementation.

Several Examples of uses are listed below:

1. Tracking your programs. Suppose you wish to Implement an Active Directory Project in your enterprise. You can now enter Active Directory as a subsystem, enter all the features you are implementing as Feature Requirements and then trace those to the Enterprise Requirements from the NIST. This will allow you to not lose sight of your goals, and also see what portion of the NIST Control set will be implemented with your project. Also, it will quickly allow you to see that there may be features you are missing. For example, you may notice that AC-7 Unauthorised Login Attempts does not is not traced from your Active Directory Feature set, indicating you have a gap in your project implementation.
2. Highlighting Gaps as part of your risk assessment. After entering your existing projects as subsystems and tracing their features back to your master Enterprise requirements, you can see what controls are not implemented. You now can fix your gaps by implementing policies, starting new projects, etc.
3. Issue an RFP to fix your gaps. Use the gaps as a requirements list for an RFP to hire a vendor and use the same list to evaluate vendor responses.
4. Highlight key areas. Using the attributes of each Enterprise requirement, you can prioritize your work. Standard Attributes for each requirement can include Priority (Critical, High, Medium, Low) and Implementation (Easy, Moderate, Difficult). This way you can see your critical needs and even prioritise them in order of difficulty. You can improve your security posture the best by selecting your Critical needs that are easy to do….
5. Features that do not have a Enterprise control that they can map to. This tells you one of three things. Either you have a feature that isn’t needed, you aren’t fully aware of which control it would trace to, or your Enterprise set is lacking. If your Enterprise set is lacking, then you need to perhaps add additional control sets to support your primary control set.

In summary, implementing your selected control set into a Requirements Management Program is a great way to track your information protection controls and ensure you are aware of and addressing existing gaps in your program. This will greatly enhance your information protection posture and may even help defending programs or prepare for Information Systems Audits at the management level.

Currently a Major Government Agency is implementing Requisite Pro in this manner using the NIST as a master list of Enterprise Controls. HIPAA Security Rules have been added as Business Rules that trace from the NIST control set, ensuring that all controls will be tracked over implementation of Information Security Projects.

For any questions, assistance on Rational Requisite Pro, OpenUP and/or information security controls, feel free to contact me. Ready to import templates of NIST and ISO standards for Enterprise Requirements in Requisite Pro can be made available, depending on your Enterprise Requirements Management Plan.

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.

OR MUCH ADO ABOUT MAPPING 

Within the IT Governance and Information Security fields there are many requests for mapping one standard to another to ease implementation of standards and provide additional guidance where needed. However, one caution is that not all mapping is created equal and in no case should  one blindly follow the mappings provided without understanding the standards themselves and how they are implemented. In other words, mappings should only be used as a touchstone or starting point and not th e definitive guidance for implementation. 

COBIT 4.1 , ISO 27002:2005 (formerly ISO 17799:2005) and NIST SP 800-53 Rev 2 all are mapped to each other in various documents. For brevity, these standards will be referred to COBIT, ISO and NIST for the rest of this post. Luckily the COBIT mappings also provide a qualitative assessment of how well ISO control objectives and controls and NIST controls fufill the COBIT Control Objectives. The NIST mapping does not provide that qualitative assessment, however they provide similar cautions that I am discussing.

A short illustrative example of the dangers in blindly following mapping is illustrated below:

In the COBIT Mappings I selected three simple control objectives that both NIST and ISO fufilled completely. The image below illustrates the mappings. (Click to Open the Image Fully)

I selected those COBIT Control Objectives as the each have only one NIST and one ISO control that completely fills the COBIT Control Objective and should be easy to compare.  One would expect that at a minimum, mapping the same NIST Controls to ISO would show the same ISO  Controls and Objectives as those listed under the COBIT mapping. The table below shows the NIST mapping of those same controls (CP-3, CP-4 and CP-5) to ISO. (Click to Open the Image Fully)

Note that the ISO Control 14.1.5 that was listed as completely fufilling COBIT Control Objective DS4.6  is not present at all in the NIST Control CP-3, which was also listed as completely fufilling COBIT Control Objective DS4.6.  The other two NIST Controls list additional ISO controls and objectives, but that MAY be OK. It may be that those additional ISO Control Objectives are truly not part of the COBIT control objective listed above and are not needed to be identified. This was simply to illustrate the dangers of blindly accepting mapping. There obviously is a difference of opinion in the mappings of the COBIT standards to ISO and NIST and the mappings of NIST to ISO as shown in this example (specifically NIST CP-3). Which is why there is no substitute to understanding the standards and applying them as you understand your requirements.

Mapping is not without value, but it should be used as a starting point to understanding, not as a replacement for understanding.

Without going too far down this rabbit hole, here is a slightly more complex mapping. In this case the single COBIT Control Objective is completely fufilled by a list of NIST Controls and a list of ISO Control Objectives/Controls. The assumption would be that every NIST Control should have at least one, if not more of the ISO Control Objectives/Controls mapped to it as well. However, only TWO of the NIST controls (those highlighted in Green) map to ONE of the ISO Control Objectives/Controls listed. The others (those hightlighted in Yellow) have different ISO Control Objectives/Controls and vice versa. (Again, Click to Open Image Fully)

For Further Information on Mapping these Standards Visit http://www.isaca.org and http://www.nist.gov

Feel Free to Contact Me with Any Additional Questions.