Thoughts about compliance assessments result
|
|
Sérgio Câmara
|
Some javascript/style in this post has been disabled (why?)
Hi, I work for Modulo
Security and since some time ago we’ve been concentrating our efforts on
incorporating OVAL in our product, Modulo Risk Manager. Modulo Risk Manager,
among other features, performs compliance gap analysis based on individual controls, and with this in
mind I’ll try to
explain one of the issues that have been surrounding us. For a compliance
assessment, our application can tell at most 4 result values for each control: implemented,
not-implemented, not-answered and not-applicable. Along with our
efforts to became oval-compatible, we also had to map this 4 answers into
those that OVAL provides. Here is how we’ve mapped so far: -
Implemented
à ‘true’ -
Not-implemented
à ‘false’ -
Not-answered
à ‘unknown’ or ‘error’ -
Not-applicable
à mm, we’ve got a problem here. I’ll try to
explain what is going on with the ‘not-applicable’. Suppose the
following control : ”Only the Administrators group must be granted
full-control permission to the file %path%\xyz.exe.” Now, when our
application assess this control, it would answer: -
Implemented,
when only the Administrators group have full-control. -
Not-implement,
when the Administrators don’t have the full permission, or if there is
any other group with the full permission. -
Not-applicable,
when the file ‘%path%\xyz.exe’ doesn’t exists, for example. So, the answer
‘Not-applicable’ means for us that the configuration wouldn’t
make sense because the file doesn’t exist. When running this
logic on Ovaldi, it would flag the object (fileeffectiverights53_object) as
‘does not exist’ and the test would return ‘False’
and be wrongly mapped into ‘Not-Implemented’ in our
application. If check_existence attribute was set to "any_exist", the
test would return ‘True’ and be wrongly mapped again, into “Implemented”. I’ve been
looking through the Forum archives and I found some interesting discussions
about ‘not-applicable’. At last, I realized that ‘not-applicable’
means, in Oval Language, that the running system does not support the given
object being tested. By now, we can
implement oval-tests logic that answers this kind of control as
‘unknown’ if the file doesn’t exist, keeping
‘true’ and ‘false’ for the others occurrences. Along with that, we
can also implement our own oval interpreter, aiming to output the desired
answer, but wouldn’t it make the application non oval-compatible in
some way? Even knowing that
Oval was made for vulnerability checking purposes, did someone found any
other way to solve control
answers like that? Or, is there any study that could let
OVAL handle this kind of compliance issue? Thanks in advance, Sergio Camara
(scamara [at] modulo.com.br) Modulo Security
– Solutions for GRC |
||||||||||||||||
bakerj
|
Some javascript/style in this post has been disabled (why?)
Sergio, I have opened up a feature
request to track this issue. I believe this request is similar to what was
being asked for in this earlier thread too: http://n2.nabble.com/Re-Doubt-about-result-true-false-or-others-tp3663033ef20093.html In short what is needed is a
capability in oval to allow a content author to declare that the result of a
given test should be some specified value (true, false, not applicable, etc)
when a given condition is met (or not met). Is this summary correct? As you noted, if you choose to
implement your own meaning for the not applicable result you would be deviating
from the intended of that result value. The oval-results-schema says the
following about the ‘not applicable’ result value in the
ResultEnumeration: When evaluating a definition
or test, a result value of 'not applicable' means that the definition or test
being evaluated is not valid on the given platform. For example, trying to
collect Linux RPM information on a Windows system. Another example would be in
trying to collect RPM information on a linux system that does not have the RPM
packaging system installed. We will consider your feature
request for version 5.7 of OVAL. When we begin working on the release please
help us verify that any proposed solution will meet your needs. Thanks, Jon ============================================ Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: [hidden email] From: Sérgio Câmara
[mailto:[hidden email]] Hi, I work for Modulo Security and
since some time ago we’ve been concentrating our efforts on incorporating
OVAL in our product, Modulo Risk Manager. Modulo Risk Manager, among other
features, performs compliance gap analysis based on individual controls, and
with this in mind I’ll try to explain one of the issues that
have been surrounding us. For a compliance assessment, our
application can tell at most 4 result values for each control: implemented,
not-implemented, not-answered and not-applicable. Along with our efforts to became
oval-compatible, we also had to map this 4 answers into those that OVAL
provides. Here is how we’ve mapped so far: -
Implemented à
‘true’ -
Not-implemented à
‘false’ -
Not-answered à
‘unknown’ or ‘error’ -
Not-applicable à
mm, we’ve got a problem here. I’ll try to explain what
is going on with the ‘not-applicable’. Suppose the following control
: ”Only the Administrators group must be granted full-control permission
to the file %path%\xyz.exe.” Now, when our application assess
this control, it would answer: -
Implemented, when
only the Administrators group have full-control. -
Not-implement, when
the Administrators don’t have the full permission, or if there is any
other group with the full permission. -
Not-applicable,
when the file ‘%path%\xyz.exe’ doesn’t exists, for example. So, the answer
‘Not-applicable’ means for us that the configuration wouldn’t
make sense because the file doesn’t exist. When running this logic on
Ovaldi, it would flag the object (fileeffectiverights53_object) as ‘does
not exist’ and the test would return ‘False’ and be
wrongly mapped into ‘Not-Implemented’ in our application. If
check_existence attribute was set to "any_exist", the test would
return ‘True’ and be wrongly mapped again, into
“Implemented”. I’ve been looking through
the Forum archives and I found some interesting discussions about
‘not-applicable’. At last, I realized that
‘not-applicable’ means, in Oval Language, that the running system
does not support the given object being tested. By now, we can implement
oval-tests logic that answers this kind of control as ‘unknown’ if
the file doesn’t exist, keeping ‘true’ and
‘false’ for the others occurrences. Along with that, we can also
implement our own oval interpreter, aiming to output the desired answer, but
wouldn’t it make the application non oval-compatible in some way? Even knowing that Oval was made
for vulnerability checking purposes, did someone found any other way to
solve control answers like that? Or, is there any study that could let
OVAL handle this kind of compliance issue? Thanks in advance, Sergio Camara (scamara [at]
modulo.com.br) Modulo Security –
Solutions for GRC To
unsubscribe, send an email message to [hidden email] with SIGNOFF
OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write
to [hidden email]. |
||||||||||||||||
|
Sérgio Câmara
|
Some javascript/style in this post has been disabled (why?)
Hi Jon, I think your summary
is correct and maybe this capability could even contemplate other needs beyond
mine. I’ll
be following the work. Thanks, Sergio Camara
(scamara [at] modulo.com.br) Modulo Security
– Solutions for GRC From: Baker, Jon [mailto:[hidden email]] Sergio, I have opened up a
feature request to track this issue. I believe this request is similar to what
was being asked for in this earlier thread too: http://n2.nabble.com/Re-Doubt-about-result-true-false-or-others-tp3663033ef20093.html In short what is
needed is a capability in oval to allow a content author to declare that the
result of a given test should be some specified value (true, false, not applicable,
etc) when a given condition is met (or not met). Is this summary correct?
As you noted, if you
choose to implement your own meaning for the not applicable result you would be
deviating from the intended of that result value. The oval-results-schema says
the following about the ‘not applicable’ result value in the
ResultEnumeration: When
evaluating a definition or test, a result value of 'not applicable' means that
the definition or test being evaluated is not valid on the given platform. For example,
trying to collect Linux RPM information on a Windows system. Another
example would be in trying to collect RPM information on a linux system that
does not have the RPM packaging system installed. We will consider your
feature request for version 5.7 of OVAL. When we begin working on the
release please help us verify that any proposed solution will meet your needs. Thanks, Jon ============================================ Jonathan O. Baker G022 - IA Industry
Collaboration The MITRE Corporation Email:
[hidden email] From: Sérgio Câmara
[mailto:[hidden email]] Hi, I work for Modulo
Security and since some time ago we’ve been concentrating our efforts on
incorporating OVAL in our product, Modulo Risk Manager. Modulo Risk Manager,
among other features, performs compliance gap analysis based on individual controls,
and with this in mind I’ll try to explain one of the issues
that have been surrounding us. For a compliance
assessment, our application can tell at most 4 result values for each control: implemented,
not-implemented, not-answered and not-applicable. Along with our
efforts to became oval-compatible, we also had to map this 4 answers into
those that OVAL provides. Here is how we’ve mapped so far: -
Implemented
à ‘true’ -
Not-implemented
à ‘false’ -
Not-answered
à ‘unknown’ or ‘error’ -
Not-applicable
à mm, we’ve got a problem here. I’ll try to
explain what is going on with the ‘not-applicable’. Suppose the
following control : ”Only the Administrators group must be granted
full-control permission to the file %path%\xyz.exe.” Now, when our
application assess this control, it would answer: -
Implemented,
when only the Administrators group have full-control. -
Not-implement,
when the Administrators don’t have the full permission, or if there is
any other group with the full permission. -
Not-applicable,
when the file ‘%path%\xyz.exe’ doesn’t exists, for example. So, the answer
‘Not-applicable’ means for us that the configuration wouldn’t
make sense because the file doesn’t exist. When running this
logic on Ovaldi, it would flag the object (fileeffectiverights53_object) as
‘does not exist’ and the test would return ‘False’
and be wrongly mapped into ‘Not-Implemented’ in our
application. If check_existence attribute was set to "any_exist", the
test would return ‘True’ and be wrongly mapped again, into
“Implemented”. I’ve been
looking through the Forum archives and I found some interesting discussions
about ‘not-applicable’. At last, I realized that
‘not-applicable’ means, in Oval Language, that the running system
does not support the given object being tested. By now, we can
implement oval-tests logic that answers this kind of control as
‘unknown’ if the file doesn’t exist, keeping
‘true’ and ‘false’ for the others occurrences. Along with that, we
can also implement our own oval interpreter, aiming to output the desired
answer, but wouldn’t it make the application non oval-compatible in
some way? Even knowing that
Oval was made for vulnerability checking purposes, did someone found any
other way to solve control answers like that? Or, is there any study that
could let OVAL handle this kind of compliance issue? Thanks in advance, Sergio Camara
(scamara [at] modulo.com.br) Modulo Security
– Solutions for GRC To
unsubscribe, send an email message to [hidden email] with SIGNOFF
OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write
to [hidden email]. To
unsubscribe, send an email message to [hidden email] with SIGNOFF
OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write
to [hidden email]. |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
