Head of Agency
The Head of Agency is also known as the Chief Executive Officer. This role is the highest level executive senior officer within an organization. They have ultimate responsible for the providing information security protection. The level of protection must be at the same level as the importance of the information. The Department of Defense equivanent is a DoD Head of component (i.e. Secretary of the Army).

image of secretary army john mchugh

Risk Executive Function
The Risk Executive Function’s main focus is the overall risk to the entire organization. They create a risk strategy for the organization that guides mission/business process and system-level risk assessments. The Risk Executive Function is and important role for Tier 1 activities of managing risk of information systems IAW NIST SP 800-39.

CIO
Chief Information Officer is an organizational official responsible for (1) designating a senior information security officer; (2) developing and maintaining information security policies; (3) ensure that those with responsibilities in system security have proper training.

Information Owner/Steward
“The information owner/steward is an organizational official with statutory, management, or operational authority for specified information and the responsibility for establishing the policies and procedures governing its generation, collection, processing, dissemination, and disposal.” NIST SP 800-37 The Information Owner must coodinate with the Information System Owner (DoD PM equivalent) for decisions involving the overall system.

Senior Information Security Officer
The SISO is directly responsible to the CIO. They’re focus is the information security of the organization’s data. They act as a liaison between CIO and the Authorizing Official. The DoD equivalent (circa 2010) is known as the Senior Information Assurance Officer (SIAO).

Authorizing Official
AO formally accepts the risk of a system in the Implementation/Assessment phase of the System Development Lifecycle and Step 5, Authorization step of the Risk Management Framework.

Common Control Provider

“The common control provider is an individual, group, or organization responsible for the development, implementation, assessment, and monitoring of common controls.” NIST SP 800-37. A common control is a security controls that covers multiple information systems within and organization. Examples of common controls: Incident Response, Network boundary protection (firewalls, IDS/IPS).

Information System Owner
“The information system owner is an organizational official responsible for the procurement, development, integration, modification, operation, maintenance, and disposal of an information system.” NIST SP 800-37

Information System Security Engineer
“The information system security engineer is an individual, group, or organization responsible for conducting information system security engineering activities.” NIST SP 800-37 The ISSE implements security into the design of systems. The ISSE is often a consultant or Subject Matter Expert who focus is applying information assurance frameworks and regulations in an information system.

Information System Security Officer
This role is initiated at the Initial phase of the System Development Lifecycle (SDLC). “The information system security officer
is an individual responsible for ensuring that the appropriate operational security posture is maintained for an information system and as such, works in close collaboration with the information system owner” NIST SP 800-37. This role has been called and Information Assurance Officer (IAO) within the Department of Defense. Within the DoD this role is appointed by the Information Assurance Manager (IAM). Also known as the Information System Security Manager (ISSM). The ISSM is often responsible to over site and being a supervisor of ISSO positions.

Security Control Assessor
“The security control assessor is an individual, group, or organization responsible for conducting a comprehensive assessment of the management, operational, and technical security controls employed within or inherited by an information system to determine the overall effectiveness of the controls” NIST SP 800-37.

The NIST & DoD have very similar roles with different names:

Risk Assessments and Risk Management will apply to National Security Systems (NSS).

What is a Risk Assessment?

A risk assessment is the results/process to determine the likelihood that a threat will exploit a weakness. Risk assessment is a part of the risk management.

What is risk management?

Risk Management is the on-going process of determining assessing, identifying and prioritizing of risks.

Is My System a National Security System?

NIST SP 800-59, Guidance for Identifying an information system as an NSS. 800-39 is a 17 page document developed in conjunction with the Department of Defense, including the National Security Agency, for identifying an information system as a national security system. It is basised on the Federal Information Security Management Act of 2002 (FISMA).

Who determines if you have an NSS?

The head of each agency is responsible for designating an agency information security official to determine which, if any, agency systems are national security systems.

Tools to determine if you have a NSS system:

National Security System Identification Checklist (NIST SP 800-59, Appendix A). The NSS ID Checklist asks (6) questions. Answering yes to any of these questions qualifies your system as an NSS:
• Does the function, operation, or use of the system involve intelligence activities?
• Does the function, operation, or use of the system involve cryptologic activities related to national security?
• Does the function, operation, or use of the system involve command and control of military forces?
• Does the function, operation, or use of the system involve equipment that is an integral part of a weapon or weapons system?
• Is the system critical to the direct fulfillment of military or intelligence missions?
• Does the system store, process, or communicate classified information?

NSS RMF
The guidance of CNSSI 1253 is the result of NIST collaborated with the Intelligence Community (IC), Department of Defense (DoD), and the Committee on National Security Systems (CNSS) to ensure NIST SP 800-53 contains security controls to meet the requirements of National Security Systems (NSS).

KEY DIFFERENCES BETWEEN CNSS INSTRUCTION NO. 1253 AND NIST PUBLICATIONS

The key differences between CNSSI 1253 and the rest of the NIST publications is that NSS systems do not follow “high-water mark”, NSS maybe tailored through risk-based adjustment, control profiles, and a method that allows organization to practice reciprocity.

NSS and High Water Mark
Both FIPS 200 and NIST 800-53 apply the concept of a high-water mark (HWM) when categorizing information systems according to the worst-case potential impact of a loss of confidentiality, integrity, or availability of information or an information system. This Instruction does not adopt this HWM usage. In the National Security Community, the potential impact levels determined for confidentiality, integrity, and availability are retained, meaning there are 27 possible three-value combinations for NSI or NSS, as opposed to the three possible single-value categorizations obtained using the guidelines in FIPS 200. – CNSSI 1253

Risk-Based Adjustment
Potential impact-based security categorizations for NSS may be tailored through the use of a risk-based adjustment. This adjustment takes into consideration the physical and personnel security measures already employed throughout the National Security Community and factors such as aggregation of information.

Control Profile
Method by which organizations may designate sets of controls for NSS based on their enterprise-wide risk assessment and taking into account business objectives, system risks, and mission needs.

NSS Reciprocity
It is the policy of the National Security Community that member organizations practice reciprocity with respect to the certification of systems and system components to the greatest extent practicable. Reciprocity of certification reduces the cost and time to implement systems and system components.

A risk assessment is the results/process to determine the likelihood that a threat will exploit a weakness. Risk assessment is a part of the risk management.

What is risk management?

Risk Management is the on-going process of determining assessing, identifying and prioritizing of risks.

STEP of a RISK ASSESSMENT

This is a synopsis of NIST Special Publication 800-30. These are steps that should be a part of an IT risk management plan

Step 1 System Characterization

An organization must know all the parts of a new information system before the threats, vulnerabilities can be identified and impact (or harm) to the organization can be analyzed. System characterization includes the a list of the hardware, software, firmware and network diagram. System characterization also includes the operational environment that the system is in, any management, operational, technical controls implemented.

Additional features and methods of system characterization are described in 3.1 of NIST SP 800-30. The output looks a lot like a System Security Plan. NIST 800-18, Guide for Developing Security Plans for Federal Information Systems characterizes system in section 2.-System Boundary Analysis & Security Controls and section 3.- Plan Development.

Output from Step 1-Characterization of the IT system assessed, a good picture of the IT system environment, and delineation of system boundary

Step 2 Threat Identification

A threat is “the potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.” A threat-source is “Either (1) intent and method targeted at the intentional exploitation of a vulnerability or (2) a situation and method that may accidentally trigger a vulnerability.” an adverse action or event that could exploit or trigger vulnerability. NIST identifies three “common threat-sources” Natural, Environmental, Human.

Common Threat-Sources
- Natural Threats—Floods, earthquakes, tornadoes,
landslides, avalanches, electrical storms, and other such
events.
- Human Threats—Events that are either enabled by or
caused by human beings, such as unintentional acts
(inadvertent data entry) or deliberate actions (network
based attacks, malicious software upload, unauthorized
access to confidential information).
- Environmental Threats—Long-term power failure,
pollution, chemicals, liquid leakage.

Sources of information include, but are not limited to, the following:
• Intelligence agencies (for example, the Federal Bureau of Investigation’s National Infrastructure Protection Center)
• Federal Computer Incident Response Center (FedCIRC)
• Mass media, particularly Web-based resources such as SecurityFocus.com, SecurityWatch.com, SecurityPortal.com, and SANS.org. – NIST 800-30

By addressing the motivation behind a potential attack, the capability of the event to occur, and the available resource of a potential attacker, an organization can have a better idea of the likelihood of real threat-sources.

Output from Step 2 – A threat statement containing a list of threat-sources that could exploit
system vulnerabilities

Step 3 Vulnerability Identification

A vulnerability is a weakness in a systems design, architecture, configuration etc that could be exploited. There are many ways to find vulnerabilities on a system. Federal systems have the Vulnerability Management System (VMS) and National Vulnerability Database which are databases with a breakdown of operating system, network, application vulnerabilities that can allow an organization to track vulnerabilities. Network vulnerability scans, security test & evaluations, interviews, questionnaires, POA&Ms, penetration tests and previous assessments are other methods of identifying vulnerabilities.

Step 4 Control Analysis

Control analysis consist of listing all controls that are planned and implemented. Actions to identify planned and implemented controls could include examining previous POA&Ms & system security plans on existing systems. On new systems the organization could examine nontechnical and technical controls to be implemented by using network scanners, scripts. For nontechnical controls, the organization could observe documentation addressing business/mission procedures and organization policies.

http://nvd.nist.gov/scap/docs/2008-conf-presentations/day2/mgt-80037-transformation-ross-092408.pdf

Step 5 Likelihood Determination
Likelihood determination is based on threat-source motivations, capability, and resources available combined with the nature of system vulnerabilities.

The organization creates likelihood levels and definitions for the development of qualitative determination.

Step 6 Impact Analysis
Impact analysis takes determination of the system mission, the system and data criticality/sensitivity. The organization should determine the adverse impacts of the loss of integrity, confidentiality, or availability.

The organization can give examples of quantitative assessments by introducing real profit loss as a result of impacts. The magnitude of impact/impact definition is represents a qualitative matrix above.

Output from Step 6-Magnitude of impact (High, Medium, or Low)

Step 7 Risk Determination
The risk determination consists of the likelihood of a given threat and the magnitude of the impact should a vulnerability be exploited/engaged by a threat-source. The output of this step is a Risk-Level Matrix. Threat likelihood and potential impacts are given a rating system.

Step 8 Control Recommendations
The goal of the control recommendation is to determine how the mitigate identified vulnerabilities to reduce risk to the system.
• Effectiveness of recommended options (e.g., system compatibility)
• Legislation and regulation
• Organizational policy
• Operational impact
• Safety and reliability

Step 9 Document findings
All the results of the risk assessment methodology must be documented. A Security Assessment Report (SAR) or risk assessment report captures data that will allow decision makers to make an inform decision on cost benefit for implementing controls.

But if your position actually requires you to take an IAM roles at the Field Operating Agency enlcave systems or some other MAJCOM equivalent level than you should go for the CISSP. The DoD is talking about requiring an **Information System Security Engineering Professional certification, ISSEP (a certification that actually requires the CISSP to even take the test) for enclave systems.

This table is taken straight from the DoD 8570.01M:

from tao security

More on the 8570:

http://iase.disa.mil/eta/index.html#8570training

**Notes: The 8570 FAQ mentions that “Future updates to the Manual will incorporate specialized elements of the IA workforce. Chapters on System Architecture and Engineering and Computer Network Defense Service Providers have been drafted and are currently entering the formal DoD staffing process.” I haven’t been able to find the new 8570 Draft that refers to ISSEP, ISSAP (specialized CISSP) but I’ve been seeing it in slides and at briefing for about a year now.

Here is what is being proposed. This would actually affect me (I may have to get an ISSEP or ISSAP). Security+ will not cut it if this passes in the next DoD 8570 Draft.

Chapter 10: Information Systems Security Architects/Engineers
Level IASAE I IASAE II IASAE III
Certs CISSP CISSP ISSEP
ISSAP
Chapter 11: CND Service Providers
Role CND Analyst CND
Infrastructure
Support CND Incident Responder CND
Auditor CND SP Manager
Certs GCIA MCSA Security
SSCP GCIH
CSIH CISA
GSNA CISSP-SSMP
CISM

Ref: www.disa.mil/conferences/2007/briefings/iatool_training.ppt (slide 19 from DISA Conference)

Tags: 8570, issep, cissp, certification

As of right now, I have a CISSP.  I do a lot of Security Testing Evaluations and Authorization Agreement, Security Policy type work.  It pays well but I think Pen Testing would be more fun.  After getting the CISSP, I seriously considered going after the ISSEP, Information System Security Engineering Professional cert, which I heard was harder than the CISSP… I don't see how that is possible.

The CEH is a 125 question test that I've heard mixed reviews about.  I've taken the bootcamp and I love the material.  Its all hardcore hacking.  Not simply how to use Cane & Abel or NMap but how to code malware with notepad, methods of SQL injection, and firewall attacks.  I learned a lot.  It also scared the piss out of me.  If your already a hacker or hardcore pent tester than the class would be nothing more than a refresher.  Intermediates with pentesting will have a real treat.  Beginers will be decapitated.

I guess CPTE, Certified Pen Testing Expert is the lastest one.  From what I've read, it looks like it is a step up from the CEH.  Here is some more info on the CPTE.  From what I've read the CPTE is INSANE.  It looks like a practical exam completed in the presents of a pentesting expert.  It includes SQL injections, gathering data, compiling hacker applications, and FRICKING Lockpicking… I AM NOT READY. 

I've been thinking of taking the Information System Security Engineering Professional (ISSEP) certification.  Since the CISSP info is still fresh in my mind and much of the ISSEP are things I do or have to deal with daily it seems like a good idea. 

What is the ISSEP?
The ISSEP was developed by the International Information System Security Certification Consortium (ISC)2 in conjuction with the National Security Agency/IAD. Where as the CISSP is an all encompassing general look at security, the ISSEP is a concentration on system security engineering process.  System security engineering has to do with ensuring that selected solutions
meet the mission or business security needs.  It is defined as “the art of and science of discovering users security needs, and designing and making with economy and elegance information
systems so that they can safely resist the forces they might be subjected to.”

System Security Engineers tasks:
  Discover Information Protection Needs
  Define system Security Requirements
  Design System Security Architectures
  Develop Detailed Security Design
  Implement System Security
  Assess Information Protection Effectiveness

Instead of ten Domains the ISSEP has four:
  System Security Engineering
  Certification and Accreditation
  Technical Managment
  U.S. Government Information Assurance Regulations 

Most of of the ISSEP's material comes from the Information Assurance Technical Framework (IATF). 

My co-worker recently took the test and he said it was more difficult than the CISSP.  The CISSP is easily THE most difficult test I've every done.  Although, since most of the information comes from the IATF, I'm not sure how it could be more difficult.
The CISSP is so broad that you could not possibly get all the information from a single source.

http://www.acsac.org/2003/case/thu-c-1530-Oren.pdf
www.nsa.gov
www.isc2.org