oval_developer@lists.cisecurity.org
A list for people interested in developing the OVAL language.
View all threadsAutomated Generation of OVAL Vulnerability Definitions for Microsoft Windows
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for now.
Feedback appreciated.
Thank you
Have a good one
...
On Sun, 01 Jan 2017 12:50:38 -0600, Jerome Athias athiasjerome@gmail.com
wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for
now.
Feedback appreciated.
Hey Jerome, that's interesting. I'm wondering, are you using the REST API
at
https://blogs.technet.microsoft.com/msrc/2016/11/08/furthering-our-commitment-to-security-updates/
to get Microsoft CVRF data ?
The CVRF for each bulletin gives a direct link to the download page for
the patch, and once downloaded you could uncompress the patch, and see
what files are located inside (and their version / branch).
Cheers,
Hassan
...
Hassan, thank you very much for the quick feedback and link to the
REST API! Much appreciated
The API looks promising, I will dig into it... (I guess would give
more than the WSUS API?)
For now, for this use case, I want to avoid having to download the patch(es).
I will investigate if it provides direct access to the updated files
list/information. (to avoid the scraping/parsing, btw finished)
(with CVRF being reviewed
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=csaf I
could have some suggestions related to that)
Thanks again!
On Thu, Jan 5, 2017 at 6:36 AM, Hassan Sultan hsultan@thefroid.net wrote:
On Sun, 01 Jan 2017 12:50:38 -0600, Jerome Athias athiasjerome@gmail.com
wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for
now.
Feedback appreciated.
Hey Jerome, that's interesting. I'm wondering, are you using the REST API at
https://blogs.technet.microsoft.com/msrc/2016/11/08/furthering-our-commitment-to-security-updates/
to get Microsoft CVRF data ?
The CVRF for each bulletin gives a direct link to the download page for the
patch, and once downloaded you could uncompress the patch, and see what
files are located inside (and their version / branch).
Cheers,
Hassan
...
On Wed, 04 Jan 2017 22:06:06 -0800, Jerome Athias athiasjerome@gmail.com
wrote:
Hassan, thank you very much for the quick feedback and link to the
REST API! Much appreciated
The API looks promising, I will dig into it... (I guess would give
more than the WSUS API?)
I haven't used the WSUS API (it requires a Windows Server, WSUS setup...
so not too fond of it) but the CVRF lists the affected platform, CVSS data
and a link to the web page (yes you still need to scrape ...) for the
patch.
The reason why I recommend the patch is because of scraping. Detecting
that you failed to download the patch or that you downloaded the wrong
patch is easy so you can alert whenever a problem occurs and once you have
the patch, you have a proper way of extracting information, while
guaranteeing the correctness of file information scraped from a web page
is a lot harder: you may have extracted all the info from the page, or
not, you don't have an obvious yes/no answer while downloading the patch
is a yes/no answer.
For now, for this use case, I want to avoid having to download the
patch(es).
I will investigate if it provides direct access to the updated files
list/information. (to avoid the scraping/parsing, btw finished)
(with CVRF being reviewed
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=csaf I
could have some suggestions related to that)
Thanks again!
On Thu, Jan 5, 2017 at 6:36 AM, Hassan Sultan hsultan@thefroid.net
wrote:
On Sun, 01 Jan 2017 12:50:38 -0600, Jerome Athias
athiasjerome@gmail.com
wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for
now.
Feedback appreciated.
Hey Jerome, that's interesting. I'm wondering, are you using the REST
API at
https://blogs.technet.microsoft.com/msrc/2016/11/08/furthering-our-commitment-to-security-updates/
to get Microsoft CVRF data ?
The CVRF for each bulletin gives a direct link to the download page for
the
patch, and once downloaded you could uncompress the patch, and see what
files are located inside (and their version / branch).
Cheers,
Hassan
--
Using Opera's mail client: http://www.opera.com/mail/
...
I definitely agree that a better way, than scraping, to obtain the
list of modified/updated files for a patch is needed.
Again, in this use case, I would like avoiding to download the patch.
With that said, I get your point, and I used to download each and
every MS patch to populate an opcode database for Metasploit (pre
ASLR/ROP era...) so yes there is value downloading the patches...
On Thu, Jan 5, 2017 at 9:23 AM, Hassan Sultan hsultan@thefroid.net wrote:
On Wed, 04 Jan 2017 22:06:06 -0800, Jerome Athias athiasjerome@gmail.com
wrote:
Hassan, thank you very much for the quick feedback and link to the
REST API! Much appreciated
The API looks promising, I will dig into it... (I guess would give
more than the WSUS API?)
I haven't used the WSUS API (it requires a Windows Server, WSUS setup... so
not too fond of it) but the CVRF lists the affected platform, CVSS data and
a link to the web page (yes you still need to scrape ...) for the patch.
The reason why I recommend the patch is because of scraping. Detecting that
you failed to download the patch or that you downloaded the wrong patch is
easy so you can alert whenever a problem occurs and once you have the patch,
you have a proper way of extracting information, while guaranteeing the
correctness of file information scraped from a web page is a lot harder: you
may have extracted all the info from the page, or not, you don't have an
obvious yes/no answer while downloading the patch is a yes/no answer.
For now, for this use case, I want to avoid having to download the
patch(es).
I will investigate if it provides direct access to the updated files
list/information. (to avoid the scraping/parsing, btw finished)
(with CVRF being reviewed
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=csaf I
could have some suggestions related to that)
Thanks again!
On Thu, Jan 5, 2017 at 6:36 AM, Hassan Sultan hsultan@thefroid.net
wrote:
On Sun, 01 Jan 2017 12:50:38 -0600, Jerome Athias
athiasjerome@gmail.com
wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for
now.
Feedback appreciated.
Hey Jerome, that's interesting. I'm wondering, are you using the REST API
at
https://blogs.technet.microsoft.com/msrc/2016/11/08/furthering-our-commitment-to-security-updates/
to get Microsoft CVRF data ?
The CVRF for each bulletin gives a direct link to the download page for
the
patch, and once downloaded you could uncompress the patch, and see what
files are located inside (and their version / branch).
Cheers,
Hassan
--
Using Opera's mail client: http://www.opera.com/mail/
...
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL would be very valuable to the community and I’d love to help.
I have spent some time working on this problem, but I didn’t take this approach (based on file/versions added by KB) and I’m hoping this works!
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting that a ton of these have already been created and contributed to the repository. I don’t know how often new inventory definitions are required, but if it turns out that we need an automated way to create these going forward as new MS products, service packs, etc are released, I think we may have one to contribute.
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over time. Microsoft patches sometimes add and remove files altogether and also can supersede other patches. For example suppose the following patches are released:
On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that was built in March based on KB 1 return a false positive? Does that make sense? I’m not sure this will be an issue in practice, but it seems like it would be.
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias athiasjerome@GMAIL.COM wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_______________________________________________
OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
http://jovalcm.com/
https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring
...
David,
thank you very much for the feedback.
see comments inline
On Thu, Jan 5, 2017 at 6:05 PM, David Ries ries@jovalcm.com wrote:
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL would
be very valuable to the community and I’d love to help.
JA> Happy if that is seen as valuable
I have spent some time working on this problem, but I didn’t take this
approach (based on file/versions added by KB) and I’m hoping this works!
JA> I just reverse engineered the latest OVAL Vulnerability Definitions
published after the 'Patch Tuesday' and automated the process of generation
JA> PoC under tests, but for Microsoft Windows Products it currently works
ok (I'm comparing the ones I autogenerate vs the latest ones published by
the community)
JA> That just seems to reduce the time for having a Definition for a
CVE/KBs from up to a month (as per my observations) to just minutes after
the CVE (with the CPEs list) is released. Note that, at this stage, for the
current scope (and due to hardcoding*), a MS- page could be enough as an
input.
JA> Note that the PoC currently heavily use Hardcoding* (which is important
for your following point)
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting
that a ton of these have already been created and contributed to the
repository. I don’t know how often new inventory definitions are required,
but if it turns out that we need an automated way to create these going
forward as new MS products, service packs, etc are released, I think we may
have one to contribute.
JA> Help is always welcome. I would see many ways for automation in this
area. (i.e. a Lab for VMs with an MSDN account and some simple code for
auto-install/update and listing of settings/values like in the registry,
etc. - I used to do that to maintain an opcode database)
JA> Going further would need a software collection (
http://www.nsrl.nist.gov/ maybe) if we would like to apply the same kind of
automated process to any kind of windows-based software (from other vendors
than Microsoft). The softwares characteristics*
(names*/settings/values/files versions/registry keys, etc.) could be
captured automatically (if not provided with SWID... or by the CVE,
CVRF/CSAF...) on a VM.
JA> Note here I used to maintain a collection of vulnerable softwares
binaries, like the one now on exploit-db
JA> Going further, if you allow me...
JA> The same automated process could be applied to Unix/Linux world, and I
guess that will be easier with the packages
JA> The process described here is applicable - now - because of the 'Big
Data' (dataset) available (thanks to the work of the community over the
past few years). And one could envision to replace the hardcoding* using AI
(see
https://www.whitehouse.gov/sites/whitehouse.gov/files/documents/Artificial-Intelligence-Automation-Economy.PDF
)
JA> I currently believe that we will live soon in a new world (Digital Age
Ref.
https://www.whitehouse.gov/sites/default/files/docs/cybersecurity_report.pdf
) with all IoTs around us, with these endpoints having enough computing
power embedded to perform automated checks on themselves (asset software
inventory, auto-update through M2M, etc.). Given that we will lack human
resources to manage these (too many) (not secure by design) IoTs endpoints
with the methods (think SACM) and softwares we have been using over the
past decades, if we want to resolve challenges like this
http://www.computerworld.com/article/3154348/security/ftc-sets-25-000-prize-for-automatic-iot-patching.html
we need to standardize and automate, and review our thinking.
JA> As of now I would think of a software based solution/function
injectable into the IoT (if not the processor yet), that would autonomously
use our 'Big Data' to manage/secure itself. (technically not so hard)
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over
time. Microsoft patches sometimes add and remove files altogether and also
can supersede other patches. For example suppose the following patches are
released:
- On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
- On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
- On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new
file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that
was built in March based on KB 1 return a false positive? Does that make
sense? I’m not sure this will be an issue in practice, but it seems like it
would be.
JA> Right now, I can't answer that. IMHO, could be valid, while I doubt
that would be a short-term issue (assuming that the Vulnerability Check
Definitions are not really expected to have a long lifetime/period of
effective use). The community of OVAL users could provide feedback
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias <athiasjerome@GMAIL.COM
athiasjerome@gmail.com> wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for
now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_____________
OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_
developer_lists.cisecurity.org
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com
[image: Joval Continuous Monitoring] http://jovalcm.com
[image: Facebook] https://www.facebook.com/jovalcm [image: Linkedin]
https://www.linkedin.com/company/joval-continuous-monitoring
...
Hi David/Jerome,
Just my two cents on the last part. If I understand it correctly, I think it wouldn’t have a false-positive result, since the OVAL definition created for the CVE-FOO will be looking for the foo.dll v1. And if the KB 3 remove it, then the OVAL definition for CVE-FOO would not be able to find it and will return a result of false indicating that the machine is not vulnerable for CVE-FOO.
Thanks,
Alexander
From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] On Behalf Of Jerome Athias
Sent: Friday, January 06, 2017 3:13 PM
To: David Ries
Cc: oval_developer@lists.cisecurity.org
Subject: Re: [OVAL DEVELOPER] Automated Generation of OVAL Vulnerability Definitions for Microsoft Windows
David,
thank you very much for the feedback.
see comments inline
On Thu, Jan 5, 2017 at 6:05 PM, David Ries <ries@jovalcm.commailto:ries@jovalcm.com> wrote:
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL would be very valuable to the community and I’d love to help.
JA> Happy if that is seen as valuable
I have spent some time working on this problem, but I didn’t take this approach (based on file/versions added by KB) and I’m hoping this works!
JA> I just reverse engineered the latest OVAL Vulnerability Definitions published after the 'Patch Tuesday' and automated the process of generation
JA> PoC under tests, but for Microsoft Windows Products it currently works ok (I'm comparing the ones I autogenerate vs the latest ones published by the community)
JA> That just seems to reduce the time for having a Definition for a CVE/KBs from up to a month (as per my observations) to just minutes after the CVE (with the CPEs list) is released. Note that, at this stage, for the current scope (and due to hardcoding*), a MS- page could be enough as an input.
JA> Note that the PoC currently heavily use Hardcoding* (which is important for your following point)
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting that a ton of these have already been created and contributed to the repository. I don’t know how often new inventory definitions are required, but if it turns out that we need an automated way to create these going forward as new MS products, service packs, etc are released, I think we may have one to contribute.
JA> Help is always welcome. I would see many ways for automation in this area. (i.e. a Lab for VMs with an MSDN account and some simple code for auto-install/update and listing of settings/values like in the registry, etc. - I used to do that to maintain an opcode database)
JA> Going further would need a software collection (http://www.nsrl.nist.gov/ maybe) if we would like to apply the same kind of automated process to any kind of windows-based software (from other vendors than Microsoft). The softwares characteristics* (names*/settings/values/files versions/registry keys, etc.) could be captured automatically (if not provided with SWID... or by the CVE, CVRF/CSAF...) on a VM.
JA> Note here I used to maintain a collection of vulnerable softwares binaries, like the one now on exploit-db
JA> Going further, if you allow me...
JA> The same automated process could be applied to Unix/Linux world, and I guess that will be easier with the packages
JA> The process described here is applicable - now - because of the 'Big Data' (dataset) available (thanks to the work of the community over the past few years). And one could envision to replace the hardcoding* using AI (see https://www.whitehouse.gov/sites/whitehouse.gov/files/documents/Artificial-Intelligence-Automation-Economy.PDF )
JA> I currently believe that we will live soon in a new world (Digital Age Ref. https://www.whitehouse.gov/sites/default/files/docs/cybersecurity_report.pdf ) with all IoTs around us, with these endpoints having enough computing power embedded to perform automated checks on themselves (asset software inventory, auto-update through M2M, etc.). Given that we will lack human resources to manage these (too many) (not secure by design) IoTs endpoints with the methods (think SACM) and softwares we have been using over the past decades, if we want to resolve challenges like this http://www.computerworld.com/article/3154348/security/ftc-sets-25-000-prize-for-automatic-iot-patching.html we need to standardize and automate, and review our thinking.
JA> As of now I would think of a software based solution/function injectable into the IoT (if not the processor yet), that would autonomously use our 'Big Data' to manage/secure itself. (technically not so hard)
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over time. Microsoft patches sometimes add and remove files altogether and also can supersede other patches. For example suppose the following patches are released:
- On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
- On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
- On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that was built in March based on KB 1 return a false positive? Does that make sense? I’m not sure this will be an issue in practice, but it seems like it would be.
JA> Right now, I can't answer that. IMHO, could be valid, while I doubt that would be a short-term issue (assuming that the Vulnerability Check Definitions are not really expected to have a long lifetime/period of effective use). The community of OVAL users could provide feedback
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias <athiasjerome@GMAIL.COMmailto:athiasjerome@gmail.com> wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_______________________________________________
OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.orgmailto:OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
David E. Ries
Co-Founder, Business Development
ries@jovalcm.commailto:ries@jovalcm.com
[Image removed by sender. Joval Continuous Monitoring]http://jovalcm.com
[Image removed by sender. Facebook]https://www.facebook.com/jovalcm[Image removed by sender. Linkedin]https://www.linkedin.com/company/joval-continuous-monitoring
...
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
...
Hi Alexander,
The way I understand the proposal (and I’m not 100% sure here) is that if foo.dll v1 does not exists, then the result of the OVAL definition will be true (vulnerable). Because foo.dll v1 is the patch for CVE-FOO. If you don’t have it on March 1st, you are vulnerable.
The key difference between this approach and most current content that I’ve seen, is that the content is not actually checking to see if you have the vulnerable component or configuration. It’s checking to see if you have the 1st fix shipped by MS.
However, in my example starting May 1st, the fact that you’re missing foo.dll doesn’t necessarily mean you’re vulnerable. The script would need to understand that KB 3 supersedes KB 1 and therefore also resolves CVE-FOO. Then the OVAL would need to be revised to check for foo.dll v1+ OR foo2.dll v1+.
The potential issue is that MS often ships rollups and other subsequent patches that supersede the initial fix and may add/remove/update all sorts of files, registry settings and etc.
Does that make sense or am I missing your point?
-David
On Jan 6, 2017, at 2:05 AM, Chua, Alexander AChua@dtcc.com wrote:
Hi David/Jerome,
Just my two cents on the last part. If I understand it correctly, I think it wouldn’t have a false-positive result, since the OVAL definition created for the CVE-FOO will be looking for the foo.dll v1. And if the KB 3 remove it, then the OVAL definition for CVE-FOO would not be able to find it and will return a result of false indicating that the machine is not vulnerable for CVE-FOO.
Thanks,
Alexander
From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org mailto:oval_developer-bounces@lists.cisecurity.org] On Behalf Of Jerome Athias
Sent: Friday, January 06, 2017 3:13 PM
To: David Ries
Cc: oval_developer@lists.cisecurity.org mailto:oval_developer@lists.cisecurity.org
Subject: Re: [OVAL DEVELOPER] Automated Generation of OVAL Vulnerability Definitions for Microsoft Windows
David,
thank you very much for the feedback.
see comments inline
On Thu, Jan 5, 2017 at 6:05 PM, David Ries <ries@jovalcm.com mailto:ries@jovalcm.com> wrote:
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL would be very valuable to the community and I’d love to help.
JA> Happy if that is seen as valuable
I have spent some time working on this problem, but I didn’t take this approach (based on file/versions added by KB) and I’m hoping this works!
JA> I just reverse engineered the latest OVAL Vulnerability Definitions published after the 'Patch Tuesday' and automated the process of generation
JA> PoC under tests, but for Microsoft Windows Products it currently works ok (I'm comparing the ones I autogenerate vs the latest ones published by the community)
JA> That just seems to reduce the time for having a Definition for a CVE/KBs from up to a month (as per my observations) to just minutes after the CVE (with the CPEs list) is released. Note that, at this stage, for the current scope (and due to hardcoding*), a MS- page could be enough as an input.
JA> Note that the PoC currently heavily use Hardcoding* (which is important for your following point)
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting that a ton of these have already been created and contributed to the repository. I don’t know how often new inventory definitions are required, but if it turns out that we need an automated way to create these going forward as new MS products, service packs, etc are released, I think we may have one to contribute.
JA> Help is always welcome. I would see many ways for automation in this area. (i.e. a Lab for VMs with an MSDN account and some simple code for auto-install/update and listing of settings/values like in the registry, etc. - I used to do that to maintain an opcode database)
JA> Going further would need a software collection (http://www.nsrl.nist.gov/ http://www.nsrl.nist.gov/ maybe) if we would like to apply the same kind of automated process to any kind of windows-based software (from other vendors than Microsoft). The softwares characteristics* (names*/settings/values/files versions/registry keys, etc.) could be captured automatically (if not provided with SWID... or by the CVE, CVRF/CSAF...) on a VM.
JA> Note here I used to maintain a collection of vulnerable softwares binaries, like the one now on exploit-db
JA> Going further, if you allow me...
JA> The same automated process could be applied to Unix/Linux world, and I guess that will be easier with the packages
JA> The process described here is applicable - now - because of the 'Big Data' (dataset) available (thanks to the work of the community over the past few years). And one could envision to replace the hardcoding* using AI (see https://www.whitehouse.gov/sites/whitehouse.gov/files/documents/Artificial-Intelligence-Automation-Economy.PDF https://www.whitehouse.gov/sites/whitehouse.gov/files/documents/Artificial-Intelligence-Automation-Economy.PDF )
JA> I currently believe that we will live soon in a new world (Digital Age Ref.https://www.whitehouse.gov/sites/default/files/docs/cybersecurity_report.pdf https://www.whitehouse.gov/sites/default/files/docs/cybersecurity_report.pdf ) with all IoTs around us, with these endpoints having enough computing power embedded to perform automated checks on themselves (asset software inventory, auto-update through M2M, etc.). Given that we will lack human resources to manage these (too many) (not secure by design) IoTs endpoints with the methods (think SACM) and softwares we have been using over the past decades, if we want to resolve challenges like this http://www.computerworld.com/article/3154348/security/ftc-sets-25-000-prize-for-automatic-iot-patching.html http://www.computerworld.com/article/3154348/security/ftc-sets-25-000-prize-for-automatic-iot-patching.html we need to standardize and automate, and review our thinking.
JA> As of now I would think of a software based solution/function injectable into the IoT (if not the processor yet), that would autonomously use our 'Big Data' to manage/secure itself. (technically not so hard)
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over time. Microsoft patches sometimes add and remove files altogether and also can supersede other patches. For example suppose the following patches are released:
On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that was built in March based on KB 1 return a false positive? Does that make sense? I’m not sure this will be an issue in practice, but it seems like it would be.
JA> Right now, I can't answer that. IMHO, could be valid, while I doubt that would be a short-term issue (assuming that the Vulnerability Check Definitions are not really expected to have a long lifetime/period of effective use). The community of OVAL users could provide feedback
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias <athiasjerome@GMAIL.COM mailto:athiasjerome@gmail.com> wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_______________________________________________
OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.org mailto:OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
<image001.jpg> http://jovalcm.com/
<image002.jpg> https://www.facebook.com/jovalcm<image002.jpg> https://www.linkedin.com/company/joval-continuous-monitoring
...
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
http://jovalcm.com/
https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring
...
Hi Jerome,
I agree, it would not be a short-term issue.
But, in my somewhat limited experience, end users who run vulnerability scans run the entire historical set of OVAL CVE definitions for the target platform in order to check for every CVE that affects that platform. The definitions can have quite a long lifetime. I think most current OVAL CVE defs check for the vulnerable components/config instead of the patch so they hold up over time.
Best,
David
On Jan 6, 2017, at 1:12 AM, Jerome Athias athiasjerome@GMAIL.COM wrote:
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over time. Microsoft patches sometimes add and remove files altogether and also can supersede other patches. For example suppose the following patches are released:
On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that was built in March based on KB 1 return a false positive? Does that make sense? I’m not sure this will be an issue in practice, but it seems like it would be.
JA> Right now, I can't answer that. IMHO, could be valid, while I doubt that would be a short-term issue (assuming that the Vulnerability Check Definitions are not really expected to have a long lifetime/period of effective use). The community of OVAL users could provide feedback
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
http://jovalcm.com/
https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring
...