Wednesday, September 12, 2007

NSA IAM and IEM Summary

Two years ago I wrote Thoughts on NSA IAM Course. That post is still in the top ten Google search results for NSA IAM, which is sad because that means there isn't much about the program online. IAM stands for INFOSEC Assessment Methodology. (Ugh, I hate "INFOSEC".)

The only real material about IAM (beyond the public slides used to teach the classes appears in Security Assessment: Case Studies for Implementing the NSA IAM by Russ Rogers, Greg Miles, Ed Fuller, Ted Dykstra. The Syngress sample chapter nicely summarizes the IAM purpose and compares it to alternatives.

The National Security Agency (NSA) Information Security (INFOSEC) Assessment Methodology (IAM) is a detailed and systematic method for examining security vulnerabilities from an organizational perspective as opposed to a only a technical perspective. Often overlooked are the processes, procedures, documentation, and informal activities that directly impact an organization’s overall security posture but that might not necessarily be technical in nature. The IAM was developed by experienced NSA and commercial INFOSEC assessors and has been in practice within the U.S. government since 1997. It was made available commercially in 2001.

NSA developed the IAM to give organizations that provide INFOSEC assessments a repeatable framework for conducting organizational types of assessments as well as provide assessment consumers appropriate information on what to look for in an assessment provider. The IAM is also intended to raise awareness of the need for organizational types of assessment versus the purely technical type of assessment. In addition to assisting the government and private sectors, an important result of supplying baseline standards for INFOSEC assessments is fostering a commitment to improve an organization’s security posture.


The following chart from the sample chapter explains how NSA differentiates security activities:



So what are the general steps proposed by NSA IAM? There are three general phases:

  1. Pre-Assessment


    • Determine and manage the customer’s expectations

    • Gain an understanding of the organization’s information criticality

    • Determine customer’s goals and objectives

    • Determine the system boundaries

    • Coordinate with customer

    • Request documentation


  2. On-Site Assessment


    • Conduct opening meeting

    • Gather and validate system information (via interview, system demonstration, and document review)

    • Analyze assessment information

    • Develop initial recommendations

    • Present out-brief


  3. Post-Assessment


    • Additional review of documentation

    • Additional expertise (get help understanding what you learned)

    • Report coordination (and writing)



NSA IAM emphasizes creating a Technical Assessment Plan (TAP) which includes the following:

  • Point of Contact

  • Mission

  • Organizational Information Criticality

  • System Information Criticality

  • Customer Concerns and Constraints

  • System Configuration

  • Interviews

  • Documents

  • Timeline of Events


In brief, the NSA IAM is a giant interview, demonstration, and documentation review that preceeds any kind of technical review. The IAM spends a good chunk of time determining Organizational Information Criticality and System Information Criticality via brainstorming and customer interviews. The idea is to narrow the scope of the assessment to something that customers care about. IAM (and IEM) sources clearly point out that their methodologies are not audits, inspections, or risk assessments. One of the course slides provides this (sort of) summary:



That's the IAM. What is the IEM [INFOSEC Evaluation Methodology]? Again, the best resource is a Syngress book -- Network Security Evaluation Using the NSA IEM by Russ Rogers, Ed Fuller, Greg Miles, Matthew Hoagberg, Travis Schack, Chuck Little, Ted Dykstra, and Bryan Cunningham. Quoting from the first chapter:

The IEM is a follow-on methodology to the NSA IAM. It provides the technical evaluation processes that were intentionally missing from the IAM. The IEM is a hands-on methodology, meaning you'll be actively interacting with the customer's technical environment. As such, the NSA intended for the IAM and IEM processes to work hand in hand...

Whereas the IAM provides us with an understanding of organizational security as it relates to policies and procedures, the IEM offers a comprehensive look into the actual technical security at the organization.


The IEM is divided into phases as well:

  1. Pre-Evaluation Phase


    • Pull information from IAM Pre-Assessment

    • Coordination with the customer to determine acceptable Rules of Engagement (ROE)

    • Give the team an understanding of the perceived system components

    • Define customer expectations

    • Define customer constraints or concerns

    • Legal Requirements

    • Develop the Technical Evaluation Plan (TEP)


  2. On-Site Evaluation Phases


    • Evaluation In-Brief

    • Tool Introduction and System Evaluation


      • Port Scanning

      • SNMP Scanning

      • Enumeration & Banner Grabbing

      • Wireless Enumeration

      • Vulnerability Scanning

      • Host Evaluation

      • Network Device Analysis

      • Password Compliance Testing

      • Application Specific Scanning

      • Network Sniffing


    • Evaluation Out Brief


  3. Post Evaluation Phase


    • Analyze the evaluation raw data

    • Conduct additional vulnerability research

    • If necessary, seek additional expertise

    • Develop recommendations

    • Coordinate final report authoring with team members

    • Deliver final report to customer



Like the IAM's TAP, the IEM directs creation of a Technical Evaluation Plan, or TEP:
  1. Points of Contact

  2. Methodology Overview


    • Purpose of the IEM

    • Description of the IEM

    • Evaluation Tools to Be Used


  3. Criticality Information (Organizational Criticality Matrices and System Criticality Information)

  4. Detailed Network Information

  5. Customer Concerns

  6. Customer Constraints

  7. Rules of Engagement

  8. Coordination Agreements


    • Level of Detail of Recommendations

    • List of Agreed-On Deliverables

    • The Coordination Agreements Section: A Catchall


  9. Letter of Authorization

  10. Timeline of Events


There's more to the IEM but those are the parts I want to have available for personal reference.

The following shows how the IAM and IEM can work together.



Is this rocket science? Of course not. Are the 10 "evaluation" activities naive and incomplete? Yes. The idea is you can build on this sort of methodology with your own approaches. I actually liked the IAM class and the structure of the IEM TEP, but I found the IEM class itself laughable.

If you want more details on really conducting evaluations, then a review of the latest Open Source Security Testing Methodology Manual (OSSTMM) is probably worthwhile.

6 comments:

Marcin said...

Hey Richard, I took the IAM and IEM training with Greg Miles last year as classes. I'd like to point out a couple of my posts that I did during the trainings:

Day 1 of NSA’s IAM
IAM Day 2
Thoughts on IEM

In IAM Day 2 post, I also include a sample TAP that we did during the class. The material and scope of the IAM is to review the security posture of an organization from a "50,000 ft view." So it may seem a bit corny, but that's what the IAM is. Of course, like you mention, it's a methodology for you to adopt and change to meet your organizational needs.

I also created a checklist of items for review from the "18 baseline categories" the NSA uses to divide technical/managerial security realms up. It's by no means comprehensive, but I was starting to run out of ideas. See here.

Richard Bejtlich said...

Marcin,

Those are excellent -- especially the .pdf's. Thank you.

-pete. said...

I have always had a problem with any framework or regulation that requires solutions. Why require AV, Firewalls, IDS, etc. rather than requiring specific security (access and interaction restrictions, etc.) or specific controls (confidentiality, integrity, subjugation, etc.)? I can't tell you how many students we must continually de-program so that they realize that a firewall is used as a point of easy central administration that introduces a single point of failure which is not required if proper architecture, segmenting, and host-based security measures and controls are in place. So NOT having one is not immediately bad as so many consider. Or those who think we NEED anti-virus on ALL our systems when they don't stop to consider it's a blacklist technology that introduces resource consumption to a computer that could go without if proper host controls are defined: even with a Windows box.

So if you are a person of authority over writing some of these rules then please please please leave solutions out of your requirements as opposed to security and controls. Security is not about solutions. It's about separation and control.

Anonymous said...

I could not agree more with -pete. All of our "requirements" are based on assumptions that will eventually breakdown over time. Solutions are specific ways of implementing controls and therefore must be relevant to the current threat environment. Since each organization's threat environment is different, we as practitioners need to have the flexibility to implement the controls in the most suitable manner and to change our implementations as new threats emerge. Being saddled with "requirements" that may in fact be based on assumptions that no longer hold true actually hurts our ability to address current threats. For example, the recommended password length for a Windows box has been 8 characters with complexity enforced basically since the dawn of time. It is in fact based on old assumptions about computing power and storage that no longer hold true, especially for Windows systems. Yet, assessments frequently state this setting as a "requirement." Requiring anti-virus software on servers is another one that I find offensive.

Anonymous said...

I love the idea of bringing security to all the employees, not just the IT folks. The IAM process sounds very much like a program designed to involve the entire enterprise in security. IBM did some work on this recently; empowering every employee to do their part in company security.
I also agree with the comments about not needing a firewall or antivirus on every machine. Each network requires different methods to secure it and the biggest exploit is the people inside the fence. Just remember, those "students" are given a fire hose of knowledge in one or two days worth of training. The instructors are quite limited in what they can teach during those few hours. They might as well teach the students the basics and let them learn from there. Expertise is only gained through experience and experience is only gained through doing it wrong until you get it right.
I am disappointed that none of the links work anymore. I was hoping to gather some great information on these ideas but the blog was done a few years back so everything seems to have changed. Thanks for the basic information though.

Anonymous said...

I took both classes and found them to be beneficial to our organization. The idea of security for everyone was a good concept, and while some of the areas were "weak" the instructor advised this was on purpose as this is for the organization to build their own ideas and methods to test and implement the practices. It was emphasized that this is a structure, not a one size fits all solution. I wish they had more of these to offer, it was a unique set of classes.