Subject: Re: [sacm] [scap-dev] Continuous Monitoring and SCAP Developer Days

From: <[email-masked]>
Date: Wed, 16 May 2012 15:16:42 -0500

Agreed and my understanding is they are reaching out as we speak.  Not sure about stump the dummy though… ;-)

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: <WOLFKIEL>, JOSEPH L CIV DISA PEO-MA <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap-dev] Continuous Monitoring and SCAP Developer Days

Any chance the Dev Days sponsors could reach out to Dept State and/or Dept Justice to discuss their current status and plans for the data they plan to collect and the metrics/scoring techniques they plan to use to build capabilities for both continuous compliance monitoring and risk scoring?

Seems like we would want to be able to play stump the dummy with the pioneers in the field.

Figuring out how SCAP will support continuous monitoring should (I think) start by understanding where continuous monitoring is evolving.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]<mailto:[email-masked]>

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, May 16, 2012 4:02 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [scap-dev] Continuous Monitoring and SCAP Developer Days

Hi All,

I know this is a bit early but I want to give everyone time to prepare for the Continuous Monitoring (CM) sessions at SCAP Developer Days. If you are attending I would encourage you to do a little homework before you come.  Let's make sure we can have highly productive sessions around Continuous Monitoring.  The following documents are the basic background needed to make real progress in the F2F. CM efforts are going to leverage existing SCAP specifications but will also need to have additional interfaces defined to be able to appropriately implement CM Instances. If we are prepared then as a group we can be much more productive and not leave anyone behind.

Here is a list of the CM related documents.

- DHS Federal Network Security (FNS) Branch - "Continuous Asset Evaluation, Situational Awareness, and Risk Scoring Reference Architecture Report (CAESARS)" - http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf

- NIST Interagency Report 7756 - CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Architecture (Draft) - http://csrc.nist.gov/publications/drafts/nistir-7756/Draft-NISTIR-7756_second-public-draft.pdf

- NIST Special Publication (SP) 800-137 - Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations -
http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf

- NIST Interagency Report (IR) 7799 - Continuous Monitoring Reference Model Workflow, Subsystem, and Interface Specifications (Draft) - http://csrc.nist.gov/publications/drafts/nistir-7799/Draft-NISTIR-7799.pdf

- NIST Interagency Report 7800 - Applying the Continuous Monitoring Technical Reference Model to the Asset, Configuration, and Vulnerability Management Domains (Draft) - http://csrc.nist.gov/publications/drafts/nistir-7800/Draft-NISTIR-7800.pdf

Thanks!

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com <http://www.mcafee.com/>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 17 May 2012 13:08:38 -0400

An unreported/untested/mis-reported check is really not related to your 
actual exposure.  Id est, a result of "not checked," "not reported," 
"error," etc, don't give you an indication of whether or not you have an 
actual exposure to attack or not, but they might be an indication of a 
procedural issue, content error, software error, and so on.

The remediation for each is different, but folding all into a single 
score loses the information necessary to apply the proper remediation. 
And giving unreported checks a higher score means you might be spending 
limited resources dealing with exposures that you aren't actually 
susceptible to.

At the same time an unreported result for a check whose exposure is 
minimal is also not the highest priority.

So it sounds like what you're looking for is to preserve both the 
severity of the check along with the result.  Then you have the 
information to decide if the solution is a technical fix vice an 
administrative action.

--gun

On 5/17/2012 12:13 PM, WOLFKIEL, JOSEPH L CIV DISA PEO-MA wrote:
> Maybe a little rationale is required.
>
> First, CVSS is a type of "severity" measurement.  It measures a relative risk of one vulnerability at a time.  It doesn't apply across multiple vulnerabilities (i.e. comparing two patches that each remediate multiple vulnerabilities). It also doesn't apply to protective measures, for example the value of deploying or not deploying an AV or HIPS signature or of having a specific service active on a device.  While CVSS is useful in assigning severities to individual vulnerabilities, it's not sufficient to build risk scores for all the types of data we need to quantify, measure, and score.
>
> Based on what I ~think~ we learned from Department of State, we have assigned different scoring methodologies to be applied to different data.
>
> The worst state we can possibly be in is ignorance, effectively "not checked" or "not reported" since we can't apply countermeasures if we don't know the state of a given vulnerability/configuration.  Also, from a human perspective, we don't ever want to reward someone for withholding information, so I generally want to reserve the right to treat "not checked" or "not reported" as being worse than "fail."
>
> "error" and "fail" can be considered about the same, but (in known cases), some checks may return an "error" condition when run on a subset of endpoints that isn't directly related to the security of the configuration.  In those cases, we'll want to assign different severities to "error" than to "fail."
>
> Finally, "fixed" is (I think) an attestation made by a human that they are overriding sensor data due to applying a non-supported remediation action.  I'd like the flexibility to associate a different level of risk with human reported data versus sensor reported data.
>
> I suppose my question is really whether others agree that we need to preserve the ability to assign different risks per finding versus being rigidly forced to only be able to assign either a fixed severity or no severity at the rule level.
>
> Joseph L. Wolfkiel
> Engineering Group Lead
> DISA PEO MA/IA52
> (301) 225-8820
> [email-masked]
>
>
> From: Wilson, David [mailto:[email-masked]]
> Sent: Thursday, May 17, 2012 9:40 AM
> To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; [email-masked]; [email-masked]
> Cc: Clingaman, Rodney J CTR DISA PEO-MA
> Subject: RE: Finding Severity Assignments
>
> Joe, I may be missing the difference between what you're calling a severity and its relationship, or not, to other scores such as CVSS....
> At any rate, I like the latter: "severities should be assigned at the rule ID level and only two possible outcomes be possible where if you fall in one group you get the severity added to your score and if you fall in the other, you don't."
> In other words, your results of pass, N/A, and fixed should have no severity.
>
> David Wilson | Director of CyberSecurity Strategy
>   (703)726-2238 o  |  (571)274-9946 c
> [email-masked] | twitter.com/djwils285
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
> Sent: Thursday, May 17, 2012 8:35 AM
> To: [email-masked]; [email-masked]
> Cc: Clingaman, Rodney J CTR DISA PEO-MA
> Subject: [scap-dev] Finding Severity Assignments
>
> Not sure where/how to broach this subject, but I was working with one of our developers yesterday and we were discussing the assignment of severities to findings to generate scores.
>
> The question is whether severities should be assigned to XCCDF rule IDs, or to the tuple of (ruleID, result).
>
> I'm currently of the mind that we'll have to track severities at the tuple level due to the ambiguity and potentially changing nature of how we allocate severities to findings.
>
> For example, a given rule (in XCCDF) can have results of pass, fail, not checked, error, not applicable, or fixed.
>
> We can assign a severity of "3" to a group that includes [fail, error], a severity of 4 to [not checked], 1 to "fixed", and 0 to [pass, not applicable].
>
> Do we need this level of flexibility, or can/should severities be assigned at the rule ID level and only two possible outcomes be possible where if you fall in one group you get the severity added to your score and if you fall in the other, you don't?
>
> As an aside, I've decided to call the "quantity" of "risk" or "added vulnerability" per finding a "severity", and call the sum of one or more severities allocated to an asset due to "findings" a "score."  Not sure if that fits within standard terminology.  Feel free to correct me if I got it wrong.
>
> Joseph L. Wolfkiel
> Engineering Group Lead
> DISA PEO MA/IA52
> (301) 225-8820
> [email-masked]
>
>
>
>
>
> _______________________________________________
> scap-dev mailing list
> [email-masked]
> To unsubscribe, send an email message to [email-masked].

---

From: Blake Frantz <[email-masked]>
Date: Thu, 17 May 2012 16:19:47 +0000

It seems the Rule/@severity attribute may have some relationship to the Rule/@weight attribute. Is that true in your use case? 

If we throw CCSS into the mix, the @weight attribute would be based on the actual state found on the box, not necessarily the outcome of the Rule's evaluation. 

It's my understanding the SCAP 1.2 allows tools to override Rule/@weight at runtime with a dynamically selected CCSS rating. Perhaps a dynamically set @severity attribute makes some sense too. 

Blake

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Thursday, May 17, 2012 5:38 AM
To: [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: [scap-dev] Finding Severity Assignments

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

...

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.

---

From: "Kinney, Michael A" <[email-masked]>
Date: Thu, 17 May 2012 12:29:01 -0400

Joe,
Glad you mentioned configuration, Is DISA going to provide the DoD with
CCSS scoring now that the Spec is final? Are you thinking we will we
need a separate metric for patches instead of adding up the CVSS score
for each? In the case where we decide to blacklist adobe while we are
waiting for a patch would you score this differently because it was
mitigated and then a different value once a patch was applied and adobe
was no longer blacklisted? How diluted will each score become as we add
different scoring mechanisms and how complex will this become? I think
the Department Of State used a much simpler metric, unless I'm mistaken.

v/r

Mike Kinney
Computer Network Defense Research and Technology (CND R&T) Office
9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: 968-8886
Fax 410-854-4681
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Thursday, May 17, 2012 12:13 PM
To: Wilson, David; [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: Re: [scap-dev] Finding Severity Assignments

First, CVSS is a type of "severity" measurement.  It measures a relative
risk of one vulnerability at a time.  It doesn't apply across multiple
vulnerabilities (i.e. comparing two patches that each remediate multiple
vulnerabilities). It also doesn't apply to protective measures, for
example the value of deploying or not deploying an AV or HIPS signature
or of having a specific service active on a device.  While CVSS is
useful in assigning severities to individual vulnerabilities, it's not
sufficient to build risk scores for all the types of data we need to
quantify, measure, and score.

Based on what I ~think~ we learned from Department of State, we have
assigned different scoring methodologies to be applied to different
data.  

The worst state we can possibly be in is ignorance, effectively "not
checked" or "not reported" since we can't apply countermeasures if we
don't know the state of a given vulnerability/configuration.  Also, from
a human perspective, we don't ever want to reward someone for
withholding information, so I generally want to reserve the right to
treat "not checked" or "not reported" as being worse than "fail."

"error" and "fail" can be considered about the same, but (in known
cases), some checks may return an "error" condition when run on a subset
of endpoints that isn't directly related to the security of the
configuration.  In those cases, we'll want to assign different
severities to "error" than to "fail."

Finally, "fixed" is (I think) an attestation made by a human that they
are overriding sensor data due to applying a non-supported remediation
action.  I'd like the flexibility to associate a different level of risk
with human reported data versus sensor reported data.

I suppose my question is really whether others agree that we need to
preserve the ability to assign different risks per finding versus being
rigidly forced to only be able to assign either a fixed severity or no
severity at the rule level.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

-----Original Message-----
From: Wilson, David [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 9:40 AM
To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: RE: Finding Severity Assignments

Joe, I may be missing the difference between what you're calling a
severity and its relationship, or not, to other scores such as CVSS....
At any rate, I like the latter: "severities should be assigned at the
rule ID level and only two possible outcomes be possible where if you
fall in one group you get the severity added to your score and if you
fall in the other, you don't."
In other words, your results of pass, N/A, and fixed should have no
severity.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Thursday, May 17, 2012 8:35 AM
To: [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: [scap-dev] Finding Severity Assignments

Not sure where/how to broach this subject, but I was working with one of
our developers yesterday and we were discussing the assignment of
severities to findings to generate scores.

The question is whether severities should be assigned to XCCDF rule IDs,
or to the tuple of (ruleID, result).

I'm currently of the mind that we'll have to track severities at the
tuple level due to the ambiguity and potentially changing nature of how
we allocate severities to findings.

For example, a given rule (in XCCDF) can have results of pass, fail, not
checked, error, not applicable, or fixed.

We can assign a severity of "3" to a group that includes [fail, error],
a severity of 4 to [not checked], 1 to "fixed", and 0 to [pass, not
applicable].

Do we need this level of flexibility, or can/should severities be
assigned at the rule ID level and only two possible outcomes be possible
where if you fall in one group you get the severity added to your score
and if you fall in the other, you don't?

As an aside, I've decided to call the "quantity" of "risk" or "added
vulnerability" per finding a "severity", and call the sum of one or more
severities allocated to an asset due to "findings" a "score."  Not sure
if that fits within standard terminology.  Feel free to correct me if I
got it wrong.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

---

From: "Ronayne, James K." <[email-masked]>
Date: Thu, 17 May 2012 13:37:15 -0400

This is a custom scoring system.  What you described seems completely
valid (although I think you might want the result score to be a
multiplier on the CVSS/CCSS value - not reported might be worth
1.1*value, fixed 0.2*value).  I think the question is how the standards
relate to custom scoring systems.  You could define your scoring system
as an extension to XCCDF.  At various times we have also considered
removing scoring from XCCDF altogether or at least making it possible to
not include scores in results.  In general I agree we would prefer our
scoring data to be handled separate from our results data.  Do we need a
means to, in a standard way, communicate details of a scoring system?
Will this become more important as continuous monitoring becomes more
common?  These details might include both values or modifiers for each
item and a formula for combining items.  We already have feeds for
things like CVE-CVSS.  We would still need feeds to describe how to
modify and combine those scores for a given set of rules.  The simplest
form of this would be the scoring system descriptions that are already
part of XCCDF.  Do we expect a results consumer to also consume standard
scoring data and present results?  The alternative is to implement
proprietary scoring schemes based on standards data where possible.

On a somewhat related note - we will probably have to do something about
scoring in XCCDF when we start using OCIL more.  Today an OCIL result of
NOT TESTED gets translated to an XCCDF result of NOT CHECKED.  NOT
CHECKED results are not included in any of the existing scoring system
calculations.  That made sense with OVAL but I don't think it works for
OCIL.

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Thursday, May 17, 2012 12:51 PM
To: Blake Frantz; [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: Re: [scap-dev] Finding Severity Assignments

In general, I don't see our scoring as being directly linked to XCCDF
content.  The concept is similar, but scoring will take place in a
central location and may address other attributes, to include network
zone, mission affiliation, threat environment, etc that will be
calculated and scored at report generation time versus assessment
runtime.

We also have tentative requirements to generate results against multiple
scoring systems for the same finding (i.e. local DAA versus US Cyber
versus Fed Gov), so I generally resist using any severities that are
hard-coded into SCAP content.

We're currently using the DISA FSO-assigned "CAT" score as the basis for
STIG severities, which may or may not have any correlation to what's in
the FDCC/USGCB content.

I should also note that we're scoring a lot of data that isn't the
result of SCAP content (AV and HIPS .dat file dates, required software
compliance) and have plans to score others (blacklisted software, port &
protocol usage, HIPS policy application, Data Loss Prevention policy
compliance, running services, WAP policy compliance, etc.).  In this
space, I want to use the same methodology across the board, whether the
data originated from SCAP or not. 

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

-----Original Message-----
From: Blake Frantz [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 12:20 PM
To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: RE: Finding Severity Assignments

It seems the Rule/@severity attribute may have some relationship to the
Rule/@weight attribute. Is that true in your use case? 

If we throw CCSS into the mix, the @weight attribute would be based on
the actual state found on the box, not necessarily the outcome of the
Rule's evaluation. 

It's my understanding the SCAP 1.2 allows tools to override Rule/@weight
at runtime with a dynamically selected CCSS rating. Perhaps a
dynamically set @severity attribute makes some sense too. 

Blake

-----Original Message-----

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

...

This message and attachments may contain confidential information.  If
it appears that this message was sent to you by mistake, any retention,
dissemination, distribution or copying of this message and attachments
is strictly prohibited.  Please notify the sender immediately and
permanently delete the message and any attachments.

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 17 May 2012 18:47:37 -0400

Joe,

We will make sure we capture this in the use cases document.  If we don't adequately address it in a future revision, please let us know. ;-)

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Thursday, May 17, 2012 6:38 PM
To: Ronayne, James K.; Blake Frantz; SCAP-DEV; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: Re: [scap-dev] Finding Severity Assignments

Good discussion.  Not sure if everyone remembers, but I did propose "we" come up with a standardized understanding of what it would mean to distribute severities and scalars in a common format (see attached) over a year ago.

At the time, I couldn't drum up much interest.  I'm still not sure if the "community" is far enough along in the process to address the issue, but I really view severity maintenance as another "content" problem that would fold into an overall content repository discussion.

I'd love to start discussing this since I view the severity assignment process as a very resource-intensive process that could be done by a small number of community experts, then licensed for distribution in a business model...

This discussion is about defining the business logic for using severities once they're assigned.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

-----Original Message-----
From: Ronayne, James K. [mailto:[email-masked]]
Sent: Thursday, May 17, 2012 1:37 PM
To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; Blake Frantz; [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: RE: [scap-dev] Finding Severity Assignments

This is a custom scoring system.  What you described seems completely valid (although I think you might want the result score to be a multiplier on the CVSS/CCSS value - not reported might be worth 1.1*value, fixed 0.2*value).  I think the question is how the standards relate to custom scoring systems.  You could define your scoring system as an extension to XCCDF.  At various times we have also considered removing scoring from XCCDF altogether or at least making it possible to not include scores in results.  In general I agree we would prefer our scoring data to be handled separate from our results data.  Do we need a means to, in a standard way, communicate details of a scoring system?
Will this become more important as continuous monitoring becomes more common?  These details might include both values or modifiers for each item and a formula for combining items.  We already have feeds for things like CVE-CVSS.  We would still need feeds to describe how to modify and combine those scores for a given set of rules.  The simplest form of this would be the scoring system descriptions that are already part of XCCDF.  Do we expect a results consumer to also consume standard scoring data and present results?  The alternative is to implement proprietary scoring schemes based on standards data where possible.

On a somewhat related note - we will probably have to do something about scoring in XCCDF when we start using OCIL more.  Today an OCIL result of NOT TESTED gets translated to an XCCDF result of NOT CHECKED.  NOT CHECKED results are not included in any of the existing scoring system calculations.  That made sense with OVAL but I don't think it works for OCIL.

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Thursday, May 17, 2012 12:51 PM
To: Blake Frantz; [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: Re: [scap-dev] Finding Severity Assignments

In general, I don't see our scoring as being directly linked to XCCDF content.  The concept is similar, but scoring will take place in a central location and may address other attributes, to include network zone, mission affiliation, threat environment, etc that will be calculated and scored at report generation time versus assessment runtime.

We also have tentative requirements to generate results against multiple scoring systems for the same finding (i.e. local DAA versus US Cyber versus Fed Gov), so I generally resist using any severities that are hard-coded into SCAP content.

We're currently using the DISA FSO-assigned "CAT" score as the basis for STIG severities, which may or may not have any correlation to what's in the FDCC/USGCB content.

I should also note that we're scoring a lot of data that isn't the result of SCAP content (AV and HIPS .dat file dates, required software
compliance) and have plans to score others (blacklisted software, port & protocol usage, HIPS policy application, Data Loss Prevention policy compliance, running services, WAP policy compliance, etc.).  In this space, I want to use the same methodology across the board, whether the data originated from SCAP or not. 

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

-----Original Message-----
From: Blake Frantz [mailto:[email-masked]]
Sent: Thursday, May 17, 2012 12:20 PM
To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: RE: Finding Severity Assignments

Blake

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Thursday, May 17, 2012 5:38 AM
To: [email-masked]; [email-masked]
Cc: Clingaman, Rodney J CTR DISA PEO-MA
Subject: [scap-dev] Finding Severity Assignments

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

...