Marine Corps Assessment and Authorization (A&A) · 2017-02-15 · Marine Corps Assessment and...

Marine Corps Assessment and Authorization (A&A)

Presented By:

Josh Ingraham (USMC SCA)Naveed Mirza (C&A Analyst)

GySgt Jonathan Vaughan (C&A Analyst)

For Official Use Only

Why do I have to do this?

In accordance with OMB A-130 which called for the establishment of the Federal Information Security Management Act (FISMA): “All systems and applications supporting Federal government agencies must go through a formal Assessment & Authorization (A&A) process prior to being placed into production.”

“Plain and simple: It’s a Federal Law…”


What is A&A?

Assessment: (Formerly Certification) Independent comprehensive risk evaluation of the technical and non-technical security features and safeguards of an IS; the output of which, is used in an effort to assist the Security Control Assessor (SCA) in the provision of risk recommendation to the Authorizing Official (AO). Authorization: (Formerly Accreditation) Authorization is a formal decision by the Authorizing Official (AO) that an information system is approved to operate in a particular security mode using a prescribed set of safeguards at an acceptable level of risk.

Summary: The overall Goal of A&A is to ensure compliance to Federal Law and DoD policies and regulations.

(Please note that the A&A process is required to be performed for all Information Systems (IS) that store, process, or transmit USMC information)**DoD guidance is contained in DoDI 8510.01 and Marine Corps Guidance for the A&A process is documented in Enterprise Cybersecurity Manual (ECSM 018).**


What it’s not…


Authorization Packages (Categories)

Minor Application• Follow a streamlined approach to Authorization.• Do not constitute a complete system or business function.• Must meet criteria listed in ECSM 018.• Broken into two subcategories:

─ Desktop Application: o Reserved for desktop applications that do not communicate outside of a

specific host.o Application primary function may not be network communication.

─ Web Application: o Shares resources with existing and authorized web servers or database

servers. o Shared resources in existing authorized package will not be tested by

Validator.


Authorization Packages (Categories) (Cont.)

Major Application• Formerly an Automated information System (AIS). • Most common category of authorization.• Type authorizations fall into this category.• Evaluates a particular system (i.e., hardware, software, and firmware).

General Support System (GSS)• Formerly site accreditation, this category of authorization is used as the method

for accrediting a physical site. Sites include enclaves, bases, posts, and stations.• Type authorized systems will be linked to the Boundary section of the

corresponding GSS MCCAST package.


Commercial Internet Service Providers (C-ISP)• Justification specific.• A&A performed on any that store, process, or transmit USMC

data.• A&A performed on any purchased with USMC dollars.

Tactical Exercises• Authorized similar to GSS packages.• Tailored approach with strict timelines for submission.

Reciprocity• Mutual agreement between agencies.• Completed Security documentation from sponsoring agency

required. USMC does not use PIT risk approval method;

evaluation is performed against specific security control that apply to the IT portion of the platform

Authorization Packages (Categories) (Cont.)Unique Packages


Who’s Who in the Zoo?

Authorizing Official (AO) Security Control Assessor (SCA) Security Control Assessor Representative (SCAR) Security Control Validator (SCV) Information System Security Manager (ISSM) Information System Security Engineer (ISSE) Information System Security Officer (ISSO) Program Manager (PM) User Representative (UR)


Roles and Responsibilities (Cont.) AO

• Only appointed authority to formally accept risk.• Approves security requirement documentation for the Marine

Corps Enterprise Network (MCEN) (i.e. Memorandums of Agreement (MOA), Memorandums of Understanding (MOU), Cybersecurity Strategies, deviations from security policies).

• Can approve or deny the operation of an IS due to the security posture not being within an acceptable level of risk.

SCA• Appointed by the AO.• Provides technical expertise in the preparation and conduction

of validations.• Ensures that the AO is presented with a risk recommendation

based on validation results and content of the Security Authorization.


Roles and Responsibilities (Cont.) SCAR

• Typically located at G-6 at Marine Corps Installation regions and appointed by the AO.

• Can assists in the security assessment procedures in coordination with the cognizant SCA and SCV for IS under their Area Of Responsibility (AOR).

• Responsible for identifying and documenting security requirements that were unmet or non-compliant.

SCV• Appointed by the AO for a duration of up to two years (must

submit renewal prior expiration to retain status).• Requirements are annotated in ECSM 018.• Coordinates with Program Office to create the Test Plan for the

system. • Conducts INDEPENDENT assessment based on the security

requirements of an IS.

I don’t always Validate a system but when I do….

I’m also an ISSE on the system.


Roles and Responsibilities (Cont.)

ISSM• Appointed by the PM endorsed by the AO.• Responsible for ensuring overall compliance to federal and DoD

regulations in accordance with USMC Cybersecurity Program.• Initiates A&A process.• Coordinates with Validator to create the Test Plan for the system. • Conducts self-assessment prior to Validation.

ISSE• Appointed by the ISSM.• Integrates Cybersecurity disciplines into system design,

development, integration, and implementation. • Aids in the conduction of risk assessments and provide

recommendations for application design.


Roles and Responsibilities (Cont.)

ISSO• Appointed by the ISSM.• Develops, maintains, and updates support documentation for

authorization packages. • Assists ISSM in administrative functions to ensure that all

Cybersecurity-enabled software, hardware, and firmware are in compliance with USMC AO approved security configurations.

PM• Represents interests of the systems throughout lifecycle.• Accounts for cost, schedule, and performance reporting.• Acknowledges Information Assurance Vulnerability Alerts

(IAVAs). • With coordination with ISSM develops POA&M to address IS

discovered vulnerabilities. UR

• Represent operational interest of the user community.• Coordinates with Program Office personnel to categorize the

system.


Risk Management Framework (RMF) and the Marine Corps Assessment and Authorization Process

(MCAAP)


RMF Overview

The Risk Management Framework (RMF) for DoD Information Technology (IT) (DoDI 8510.01)

• “Formalizes set of standards and used by DoD agencies to ensure that the security posture of a given system is acceptable and is maintained throughout it’s lifecycle.”

6 Step approach used for the Authorization of Federal IT Systems. USMC guidance is ECSM-018


RMF References ECSM 018 (Assessment and Authorization) CNSSI 1253 (Security Categorization and Control Selection) DISA STIGs (Security Technical Implementation Guides) DoDI 8500.01 (CyberSecurity) DoDI 8510.01 (Risk Management Framework for Federal IT Systems) FIPS Publication 140-2 (Security Requirements for Cryptographic Modules) FIPS Publication 199 (Security Categorization) FIPS Publication 200 (Minimum Security Requirements) Federal Information Security Management Act (FISMA) of 2002 NIST Special Publication 800-18, Rev 1 (Security Planning) NIST Special Publication 800-30, Rev 1 (Risk Management) NIST Special Publication 800-37 (Applying RMF to Federal IT Systems) NIST Special Publication 800-53 Rev 4 (Recommended Security Controls) NIST Special Publication 800-53A Rev 1 (Security Control Assessment)


Why so Many References?


RMF References

Unlike previous DoD Cybersecurity authorization processes, RMF heavily relies on documents from sources that are outside of DoD. Each individual reference provides additional guidance with regards to the multiple steps within the RMF process.


References You Need to Know

DoD IS must be categorized in accordance with Committee on National Security Systems Instruction (CNSSI) 1253

Uses risk assessment methodology from NIST 800-37 and procedures from NIST SP 800-53A

Implement a corresponding applicable set of security controls outlined within NIST SP 800-53 with supplemental guidance from CNSSI 1253

DoD-specific assignment values, overlays, implementation guidance, and assessment procedures found on the Knowledge Service (KS) https://rmfks.disa.mil.

https://rmfks.disa.mil/


6 Steps of RMF

CNSSI 1253NIST SPP 800-60

NIST SP 800-53 / CNSSI 1253

NIST 800-37/NIST 800-70

NIST SP 800-53A / NIST 800-37

NIST 800-39 / NIST 800-37 / NIST 800-30

NIST 800-53A / NIST 800-137 / NIST800-30

Categorize

Monitor Select

Implement

Assess

Authorize

http://www.google.com/url?url=http://www.thecommissioningelf.net/commissioning-lessons-from-primary-care/&rct=j&frm=1&q=&esrc=s&sa=U&ei=5nwcVOyHBcX3yQTzlIE4&ved=0CDYQ9QEwEDgU&usg=AFQjCNFJzn6fSIjfiPL91quqikOoMX8ciA


Step 1: Categorize

Three Security Objectives for information and information systems:

Confidentiality: Preserving authorized restrictions on access and disclosure, including means for protecting personal privacy and proprietary information.

Integrity: Guarding against improper information modification or destruction, and includes ensuring information nonrepudiation and authenticity.

Availability: Ensuring timely and reliable access to and use of information.

Under DoDI 8510, systems are categorized using the methods in CNSSI-1253.


Security Control Families

ManagementSecurity Assessment & Authorization (CA)Planning (PL)Risk Assessment (RA)System & Services Acquisition (SA)Program Management (PM)

OperationalAwareness & Training (AT)Configuration management (CM)Contingency Planning (CP)Incident Response (IR)Maintenance (MA)Media Protection (MP)Physical & Environmental Protection (PE)Personnel Security (PS)System and Information Integrity (SI)

TechnicalAccess Control (AC)Audit and Accountability (AU)Identification & Authentication (IA)System & Communication Protection (SC)

PrivacyAuthority & Purpose (AP)Data Accountability, Audit & Risk Management (AR)Data Quality &integrity (DI)Data Minimization & Retention (DM)Individual Participation & Redress (IP)Data Security (SE)Data Transparency (TR)Data Use Limitation (UL)


Step 2: Select

Based on the tailoring of the (18) NIST 800-53 control families.

Controls are applied to systems early in the engineering lifecycle.

Specific USMC implementation includes the Defense-in-Depth Functional Architecture (DFIA) Overlay.

RMF Tag defined Overlays are applied at this level (e.g. privacy, cross domain solution. etc.). Overlays are based on the CNSSI 1253 RMF Security control requirements


Step 2: Select (DFIA) continued…

DFIA is specific to the USMC and is an inheritance model based on a Defense Level (DL) approach (DL0 through DL3). Note: a control is either implemented or inherited. If there is a shared responsibility, then the lower defense level must list the control as implemented and is responsible for maintaining the MOA/SLA.

Def

ense

Lev

el-0

: Site

/Hos

t/Use

r

Systems/Applications

Defense Level-3

Computing Environment

Defense Level-2

Enterprise CNODefense Level-1

DODIN


Step 3: Implement

Implementation of selected controls is a Program Management (PM) function that must be concurred with by the Authorizing Official (AO).

There are a multitude of publications and other regulatory guidance that are used to determine the implementation status of controls.

The Information System Continuous Monitoring (ISCM) strategy should be established during this step.

During this step much of the documentation included within the System Security Plan (SSP) is generated.

Definition: The SSP is a blueprint for the allocation and implementation of security control requirements for an information system. It defines and details how the security controls are being implemented or are planned for implementation


Step 4: Assess

This step includes the Validation of the CNSSI 1253 selected controls based on the procedures contained within the NIST SP 800-53A and leveraging the risk assessment methodology detailed with NIST SP 800-37.

Specific USMC guidance includes the incorporation of the Common Vulnerability Scoring System (CVSS). Calculations are associated with pre-determined base scores for all vulnerabilities discovered.

Note: The CVSS Calculator is embedded within MCCAST


Step 4: Assess continued…

Following the conduction of an assessment the Validator will generate a Security Assessment Report (SAR).

The SAR details the results of a Validation and ultimately influences the content of the SSP and Plan of Action and Milestones (POA&M).

The POA&M is generated by the Validator based on the results contained within the SAR.

The POA&M is designed to identify four objectives. Vulnerabilities that need to be addressed Resources required for mitigation or remediation Milestones associated with achieving remediation Scheduled completion dates for identified items


Step 5: Authorize

Authorization Decision of a system is determined by the AO based on the contents of the System Authorization Package (SAP).

The SAP is comprised of the SSP, SAR, POA&M and other relevant documentation.

The outcome of the Authorization step is the Authorization decision document. The document conveys the overall status to the information system owner whether the system is: Authorized to Operate Not Authorized to Operate

Note: The maximum authorization period for a federal information system is three years. Once a continuous monitoring strategy has been developed and assessed by a qualified Validator at least once prior to the end of the three year authorization period, the assessment results can be cumulatively applied to the reauthorization, thus supporting the concept of ongoing authorization.


Step 5: Authorize continued…

Reauthorizations can occur outside of the continuous monitoring strategy. These are often event driven and occur when significant modifications are made within the information system or within its environment. These changes include but are not limited to: Installation of a new or upgraded operating system, middleware component,

or application Modifications to ports, protocols, or services Installation of a new or upgraded hardware platform Changes to cryptographic modules or services Modifications to security controls Moving the information system to a new facility Adding new core missions or business functions Acquiring specific and credible threat information that the organization is

being targeted by a threat source Establishing new/modified laws, directives, policies, or regulations


Step 6: Monitor

Based on guidance provided within NIST 800-137, this step leverages the ISCM strategy developed during the “Implementation” step of the RMF process.

Refinement may be required based on the decision from the AO in the “Authorize” step.

Monitoring approaches leverage both manual and automated processes.

Prioritization of discovered vulnerabilities is paramount in the provision of specific remediation actions for vulnerabilities that are identified through ongoing analysis.

Requires ongoing documentation reviews and updates based on assessment results.

Note: The ISCM process does not circumvent the requirement for the conduction of Annual Security Reviews (ASRs) required by the Federal Information System Management Act (FISMA)


MCCAST Walkthrough

30


Risk Scoring


Schrodinger's Cat


Schrodinger's Validation

Schrodinger’s cat is a fun thought experiment (minus the part about torturing a cat).

Stripping out all the quantum mechanics it boils down to this: The Cat is both alive and dead , in a state of “superposition”. Observation changes the result.


WHAT??? This is Validation, not Physics

Well, let’s give you an example:• ISSM: My system is perfectly secure! I followed all of the STIGs, and I

scan every day!• C&A: Where is your Validation?• ISSM: I did one, but we can’t get it into MCCAST. You are trying to slow

me down, this system that counts ice cream cones is super important.• C&A: Where is your Validation?• ISSM: I told you it’s done. Here is my POA&M.• C&A: This POA&M is a drawing of a cat in a box (**ok, we never really got

that answer, I’m taking dramatic license)• ISSM: That’s right! We tested everything, and that’s all the findings.


Still not Physics

Cont.• C&A: So, you did the Validation, and only have findings for your Windows

OS? What about your DB server and Web Server STIGs?• ISSM: See, you’re just wasting my time now! We had a complete

Validation done. We just don’t have the results, or the SRTM. They were in MCCAST V1, but you must have lost them.

• C&A: You just built this system this year. MCCAST V1 went offline in 2015. So, you mean to tell me that you “Did the Validation, but Didn’t do the Validation”?

• …And, that’s how we get Schrodinger’s Validation. Don’t be Schrodinger!


What is a Validation?

Lets clear up some terminologyValidation

• The process of verifying compliance with the DoD/DoN/USMC cybersecurity policies.

Risk Assessment• The determination of quantitative or qualitative estimate

of risk related to a well-defined situation and a recognized threat (also called hazard).

• Under RMF, the USMC uses the Common Vulnerability Scoring System (CVSS) to calculate Risk. (**More on that later)


What is a Validation?

Vulnerability Assessment• The process of identifying, quantifying, and

prioritizing (or ranking) the vulnerabilities in a system.

Notice the difference between Vulnerability and Risk Assessments?• Discussion: What does that mean to a Validator

or ISSM? Is a “scan” good enough for an ATO?


What comprises a complete Validation?

In order to prove that a system is COMPLIANT with policies and regulations, we need to ensure that a COMPLETE set of tests are done.

Testing WILL involve technical and non-technical testing• The “non-technical checks aren’t important” argument doesn’t hold

any validity• There is no such thing as “C&A in a day”• All Validations must include all the checks and artifacts• (Am I making my point here??)


Type of tests

Controls Assessment• NIST 800-53A

STIG/SRG/USMC Policy• Manual• Benchmark

─SCAP (Technically, these are XCCDF checks. I’ll explain in a slide or two.)

Vulnerability Scans


Security hierarchy


Control Assessments

The CNSS-1253 controls act as a set of security requirements

They also act as a set of security test proceduresMCCAST produces a “Control Assessment” test

plan (see MCCAST training).• Must be exported, completed, and re-imported.• Recommended that this is done last, as STIG and

Vulnerability findings will affect these results.


Vulnerability Scans

ACAS scans look for KNOWN vulnerabilities through a process of fingerprinting a remote system.

Can look for compliance via fingerprinting, but not it’s primary purpose.• DON’T GET CONFUSED. ACAS CAN ALSO DO SCAP

SCANS, BUT WE AREN’T TALKING ABOUT THAT RIGHT NOW!


STIG/SRG/USMC Policy tests

STIG checks form the bulk of the compliance testing that will be done as part of the RMF process.

Accounts for >50% of the testing involved in a typical system.

IT IS REQUIRED!!!• Failing to COMPLETE ALL of these checks will result in

an unacceptable Validation, and could result in a “strike” on the Validator.


BREAK TIME: About to enter the SCAP Zone!!


Security Content Automation Protocol (SCAP)

SCAP is a set of languages, formats, enumerations and scoring systems, to include Prose and XML approaches.• This means that you are better off thinking of SCAP as a large

management program, not a single thing• Defined in NIST 800-126

XML languages are used for machine readable and actionable purposes• i.e. - Scanning

Prose based languages are used as an acceptable format for human readable information• i.e. – nomenclature for defining vulnerabilities


SCAP XML Languages

XCCDF - Extensible Configuration Checklist Description Format 1.2, a language for authoring security checklists/benchmarks and for reporting results of evaluating them

OVAL - Open Vulnerability and Assessment Language 5.10, a language for representing system configuration information, assessing machine state, and reporting assessment results

OCIL - Open Checklist Interactive Language 2.0, a language for representing checks that collect information from people or from existing data stores made by other data collection efforts


SCAP Reporting Formats

ARF - Asset Reporting Format 1.1, a format for expressing the transport format of information about assets and the relationships between assets and reports

AI - Asset Identification 1.1, a format for uniquely identifying assets based on known identifiers and/or known information about the assets


SCAP Enumerations

CPE - Common Platform Enumeration 2.3, a nomenclature and dictionary of hardware, operating systems, and applications

CCE - Common Configuration Enumeration 5, a nomenclature and dictionary of software security configurations

CVE - Common Vulnerabilities and Exposures, a nomenclature and dictionary of security-related software flaws


SCAP Measurement and scoring systems

CVSS - Common Vulnerability Scoring System 2.0, a system for measuring the relative severity of software flaw vulnerabilities

CCSS - Common Configuration Scoring System 1.0, a system for measuring the relative severity of system security configuration issues


Huh??? That’s a LOT of info.

What’s important??


SCAP stuff you need to know

XCCDF – The STIGs are written in this language, so you should probably know what it does.• Audience participation – Someone want to tell me what XCCDF

does? OVAL – Really important if you want to do any automated

“SCAP” testing.• So, the STIGs are written in XCCDF, but there are linkages to the

OVAL language for any of the automated checks.• For example:

─ STIG check 1 – Interview the ISSM and make sure they are updating the system POA&M

o Not really able to be automated, so there isn’t an OVAL test for this.─ STIG check 2 – Check the Windows Registry and make sure that

autorun is turned off.o The XCCDF check references the Windows OVAL language that knows how

to connect to a Windows Registry and check settings.


SCAP stuff you need to know

CPE – Integrated into the software piece of MCCAST.

CVE – Output by ACASCVSS – You will LOVE this one (and by love, I

mean like you are going to feel like the cat)


Let’s talk Test Plan

A Validation Test Plan is a holistic set of test cases that covers all relevant security regulations from the pyramid.

Audience participation time!• Which of the following check types do you think account for the

majority of the test plan?─ Vulnerability Scans─ Manual STIGs─ Benchmark STIGs─ Controls Assessment


Validation Parts

Controls Validation20%

STIG/SRG (Manual)60%

SCAP Scans15%

Vulnerability Scans5%

Percentage of Validation


Question time!

Anyone think that doing only 20% of the testing is good enough?

What are you going to miss if you don’t do the manual STIG’s?

How many STIG checks get done by the ACAS scans?

Would you ever submit homework that was 20% complete, then complain when you got an F??


Tools

DISA STIG ViewerACAS - Assured Compliance Assessment Solution SCC - Security Content Automation Protocol

Compliance Checker


DISA STIG Viewer

From IASE - ”XCCDF formatted SRGs and STIGs are intended be ingested into an SCAP validated tool for use in validating compliance of a Target of Evaluation (TOE). As such, getting to the content of a XCCDF formatted STIG to read and understand the content is not as easy as opening a .doc or .pdf file and reading it. The process can be a little confusing and trying.”• What does that mean? Well, STIG Viewer is a tool that DISA put together

make testing a bit easier. You can build out a set of tests for a specific host (TOE in DISA speak), import results, and mark up findings.

• It will be your best friend!


ACAS

DISA’s enterprise solution for Vulnerability scanning Performs TWO types of scanning (more than that, but we only want to

talk about these two)• Vulnerability scans• SCAP scans (ok, XCCDF if we want to be accurate)

The Vulnerability scans come from the DB built into the tool, and are updated as part of the DISA contract.• Findings are tied to CVE names, and contain the baseline CVSS scores

(still building up to the CVSS scoring!)


ACAS

SCAP Scanning• STIGs labeled “Benchmark” contain the OVAL test data• These can be fed directly into ACAS, and run against a host. • The results can then be imported back into STIG Viewer.


SCC

Freely available tool that will run XCCDF/OVAL/Benchmark STIG checks

Produces an “XCCDF_Results” file that can be imported into STIG Viewer

Similar in functionality to SCAP scanning with ACAS


Knowledge check


Risks


Risk Scoring

All of the testing and scan data is just that: DATA. We now need to turn it into information in the form of a Risk Assessment.

The Validator will perform the Risk Assessment using CVSS based calculations. All Risks will be thoroughly documented within MCCAST in the appropriate section, currently this is accomplished in the POA&M section of the Authorization Package.


Common Vulnerability Scoring System (CVSS)

The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impacts of IT vulnerabilities.

DISCLAIMER• The CVSS score is technically an “Impact Metric” because it lacks a key

piece of information: Threat Analysis• Eventually, we will be able to automate some of the Threat Analysis

information using the MCCAST platform, however, CVSS scoring is the first step in the evolution of a full Risk Analysis process.

• While CVSS v3 has been created and ratified by NIST, we are currently using the CVSS v2 scoring method.


Parts of CVSS

CVSS consists of three groups: Base, Temporal and Environmental.• Each group produces a numeric score ranging from 0 to 10, and a Vector, a

compressed textual representation that reflects the values used to derive the score.

The Base group represents the intrinsic qualities of a vulnerability. The Temporal group reflects the characteristics of a vulnerability that

change over time. The Environmental group represents the characteristics of a

vulnerability that are unique to a system.

Pay attention. Two groups measure the Vulnerability, one group applies it to the system.


Parts of CVSS


CVSS – Base Metrics

Access Vector (AV) - This metric reflects how the vulnerability is exploited. The more remote an attacker can be to attack a host, the greater the vulnerability score.

Access Complexity (AC) - This metric measures the complexity of the attack required to exploit the vulnerability once an attacker has gained access to the target system. For example, consider a buffer overflow in an Internet service: once the target system is located, the attacker can launch an exploit at will.• Other vulnerabilities, however, may require additional steps in order to be

exploited. For example, a vulnerability in an email client is only exploited after the user downloads and opens a tainted attachment. The lower the required complexity, the higher the vulnerability score.



Authentication (Au) - This metric measures the number of times an attacker must authenticate to a target in order to exploit a vulnerability. This metric does not gauge the strength or complexity of the authentication process, only that an attacker is required to provide credentials before an exploit may occur. The fewer authentication instances that are required, the higher the vulnerability score.• It is important to note that the Authentication metric is different from Access

Vector. Here, authentication requirements are considered once the system has already been accessed. Specifically, for locally exploitable vulnerabilities, this metric should only be set to “single” or “multiple” if authentication is needed beyond what is required to log into the system.

• An example of a locally exploitable vulnerability that requires authentication is one affecting a database engine listening on a Unix domain socket (or some other non-network interface). If the user must authenticate as a valid database user in order to exploit the vulnerability, then this metric should be set to “single.”



Confidentiality Impact (C) - This metric measures the impact on confidentiality of a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. Increased confidentiality impact increases the vulnerability score.

Integrity Impact (I) - This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and guaranteed veracity of information. Increased integrity impact increases the vulnerability score.

Availability Impact (A) - This metric measures the impact to availability of a successfully exploited vulnerability. Availability refers to the accessibility of information resources. Attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system. Increased availability impact increases the vulnerability score.

NOTICE THE CIA Metrics??These aren’t the RMF Categorization CIA values (those come later)These ARE specific to the Vulnerability


CVSS - Temporal Metrics

Exploitability (E) - This metric measures the current state of exploit techniques or code availability. Public availability of easy-to-use exploit code increases the number of potential attackers by including those who are unskilled, thereby increasing the severity of the vulnerability. • Initially, real-world exploitation may only be theoretical. Publication of proof

of concept code, functional exploit code, or sufficient technical details necessary to exploit the vulnerability may follow. Furthermore, the exploit code available may progress from a proof-of-concept demonstration to exploit code that is successful in exploiting the vulnerability consistently. In severe cases, it may be delivered as the payload of a network-based worm or virus. The more easily a vulnerability can be exploited, the higher the vulnerability score.


CVSS - Temporal Metrics

Remediation Level (RL) - The typical vulnerability is unpatched when initially published. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued. Each of these respective stages adjusts the temporal score downwards, reflecting the decreasing urgency as remediation becomes final. The less official and permanent a fix, the higher the vulnerability score is.

Report Confidence (RC) - This metric measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details. Sometimes, only the existence of vulnerabilities are publicized, but without specific details. The vulnerability may later be corroborated and then confirmed through acknowledgement by the author or vendor of the affected technology. The urgency of a vulnerability is higher when a vulnerability is known to exist with certainty. This metric also suggests the level of technical knowledge available to would-be attackers. The more a vulnerability is validated by the vendor or other reputable sources, the higher the score.

Question: What is the Report Confidence for ALL STIG findings?


CVSS – Environmental Metrics

Collateral Damage Potential (CDP) This metric measures the potential for loss of life or physical assets through damage or theft of property or equipment. The metric may also measure economic loss of productivity or revenue. Naturally, the greater the damage potential, the higher the vulnerability score.

Target Distribution (TD) - This metric measures the proportion of vulnerable systems. It is meant as an environment-specific indicator in order to approximate the percentage of systems that could be affected by the vulnerability. The greater the proportion of vulnerable systems, the higher the score.


CVSS - Environmental Metrics

Security Requirements (CR, IR, AR) - These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of confidentiality, integrity, and availability, That is, if an IT asset supports a business function for which availability is most important, the analyst can assign a greater value to availability, relative to confidentiality and integrity. Each security requirement has three possible values: “low,” “medium,” or “high.”

Guess what these are?


CVSS - MCCAST Example


CVSS Scores

• Overall Score – This is the Risk value that will be used for the assessment of this vulnerability

• See the CVSS Scoring guide (in the training section of MCCAST) for information of the other values

• Under RMF, the USMC SCA will use the HIGH WATERMARK of all CVSS scores for the System Risk level


CVSS group exercise

Review STIG ID WN12-UR-000003• For Environmental scoring, assume that this is a single server system that

allows someone to launch nuclear weapons (we may as well have fun with this). The system CIA is HHH.

• Using the calculator at https://nvd.nist.gov/CVSS/v2-calculator, score this vulnerability.


CVSS Group exercise (cont)

What did you come up with?

CVSS v2 Vector• (AV:N/AC:L/Au:S/C:C/I:C/A:C/E:H/RL:OF/RC:C/CDP:H/TD:H/CR:H/

IR:H/AR:H)

Overall Score: 8.9


Exercise Results

WN12-SO-000022: • CVSS v2 Vector:

(AV:N/AC:L/Au:N/C:N/I:N/A:N/E:ND/RL:OF/RC:C/CDP:N/TD:H/CR:H/IR:H/AR:H)

• Overall CVSS Score: 0 WN12-SO-000074:

• CVSS v2 Vector: (AV:N/AC:L/Au:N/C:C/I:N/A:N/E:F/RL:OF/RC:C/CDP:LM/TD:H/CR:H/IR:H/AR:H)

• Overall CVSS Score: 8.8


Questions?

80

Marine Corps Assessment and Authorization (A&A) · 2017-02-15 · Marine Corps Assessment and...

Documents

Transcript of Marine Corps Assessment and Authorization (A&A) · 2017-02-15 · Marine Corps Assessment and...