Vulnerator
Vulnerator copied to clipboard
Vulnerator
ACAS - NIST 800-53 control mapping
I have begun mapping Nessus plugins to 800-53 controls and CCIs. The data is in a spreadsheet. so far, I have about 240 mappings. Are you interested in the data?
@Moe0303 Absolutely - send it my way, please. I will work on serializing it out to an XML, which makes the data more usable on my end. I will script this serialization, so that any updates can be easily incorporated.
@rkotlarz I'm not really comfortable putting it out like that at this point until I get more plugins mapped. I can tell you that the vast majority (80%) of the findings are mapped to CCI 2605, SI-2 (security relevant software updates.)
@Moe0303 - Understood. I found the same discovery during our teams evaluation. Given the usage of the ACAS suite I'm surprised that this mapping hasn't been addressed and mitigated by Tenable or DISA already.
@rkotlarz Honestly, I am not surprised. Tenable is a multinational company that caters to plenty of private industry companies - the US DoD is simply one small portion of their business, and I doubt they would go through all of the effort to map every plugin just for us. The return on investment for them just isn't there.
Also, @Moe0303 , I am working on laying out a way that future updates to mappings can be easily parsed and ingested - please keep working on the mapping as you go, and I will incorporate changes over time. It's on the roadmap, there just isn't a specific release that I feel comfortable tying it to right now (maybe 6.2.0 if I can get my butt in gear on it)
@rkotlarz Yeah, I often wondered the same thing. Then again, I did a large portion of the old Retina control mapping and eEYE never did anything about that either. I guess the bottom line is that the mapping doesn't really have a security benefit. One of my concerns is that I don't want tenable or anyone else to profit off of the work.
@amkuchta Thanks. So far, I have more than 350 controls mapped. I'll keep it going.
I would be interesting in seeing the spreadsheet that was created that maps plugins to RMF controls. Can you send me a copy?
Thank you @ibjohn I am trying to figure out how I can trace the other plugin ID numbers to there proper RMF control. My Information Assurance Manager did not like that I trying to group all ACAS finding into CM-6 and SI-2.
@ibjohn It's funny that you mention these - our SCA and AO gave us explicit guidance to map everything patch-related to CM-6. @Gerosolina I'm kind of with your ISSM - it seems like a "lazy" way out (though I get why it's important right now since there is no way to map everything yet... I'm actually working on this portion of v6.2.0 today!)
@amkuchta can you share your methodology on how you are mapping ACAS plugin IDs to RMF controls. I can not seem to find a way to trace from ACAS plugin IDs to RMF controls.
@Gerosolina unfortunately, it is not going to be an automated functionality - users will still have to manually map the ACAS plugin ID back to applicable control(s) by hand. v6.2.0 is just going t otrack these mappings, preventing users from having to re-enter them every time a vulnerability-based artifact is created. I've attached a screenshot to show the interface that will be used:
@amkuchta I think I am missing something. I see the definitions for the RMF controls. But how are you tracing an ACAS plugin ID number to a specific RMF control? Are you just reading ACAS plugin ID and interpreting the best control it fails under or is there a way to trace it somehow?
@Gerosolina the "tracing" portion is still manual. I have yet to find a way to (reliably) automatically associate the ACAS finding back to a NIST control. Users will have the ability to manually type in ACAS plugin IDs into this above list, then select the NIST controls that apply to that plugin to create a new database of their mappings, which will then be reused throughout all of their packages. Because I have designed Vulnerator to allow users to share backend databases, these mappings will be able to be shared among the members of a single IA shop, but not "globally". In a future release, I may provide the ability to export / import mappings so that they may be shared throughout the community.
Just rhinking out loud.... Can you take the xccdf files from the benchmarks to scan a test un-STIG'd system and get the matching CCI's from the STIGs? Maybe the xccdf already has CCI's and will be in the detailed report.
On Sep 27, 2017 04:49, "Gerosolina" [email protected] wrote:
Thank you @ibjohn https://github.com/ibjohn I am trying to figure out how I can trace the other plugin ID numbers to there proper RMF control. My Information Assurance Manager did not like that I trying to group all ACAS finding into CM-6 and SI-2.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Vulnerator/Vulnerator/issues/72#issuecomment-332495922, or mute the thread https://github.com/notifications/unsubscribe-auth/AYw7-xI6ccZGF5dtFo1vAaUQH2YEW9zqks5smjYngaJpZM4LXk4a .
@ibjohn Tracing to SCAP data from .xccdf files is not the problem. I can trace SCAP scans to RMF controls. But ACAS (nessus) scans only show plugin ID numbers and what vulnerabilities a system has. There is no way to trace a plugin ID number to an RMF control.
The problem with that is the benchmarks/scap vulnerabilities don't link at all to ACAS, so there is still no way to map plugin id's to security controls. That being said, it is perfectly normal for a certain type of finding to be mapped to just one or two security controls. I would try to explain that to your IAM. MOST of the plugins in ACAS logically would only related to a very small handful of security controls.
-----Original Message----- From: ibjohn [mailto:[email protected]] Sent: Wednesday, September 27, 2017 1:21 PM To: Vulnerator/Vulnerator Cc: Subscribed Subject: [Non-DoD Source] Re: [Vulnerator/Vulnerator] ACAS - NIST 800-53 control mapping (#72)
Just rhinking out loud.... Can you take the xccdf files from the benchmarks to scan a test un-STIG'd system and get the matching CCI's from the STIGs? Maybe the xccdf already has CCI's and will be in the detailed report.
On Sep 27, 2017 04:49, "Gerosolina" [email protected] wrote:
Thank you @ibjohn https://github.com/ibjohn I am trying to figure out how I can trace the other plugin ID numbers to there proper RMF control. My Information Assurance Manager did not like that I trying to group all ACAS finding into CM-6 and SI-2.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Vulnerator/Vulnerator/issues/72#issuecomment-332495922, or mute the thread https://github.com/notifications/unsubscribe-auth/AYw7-xI6ccZGF5dtFo1vAaUQH2YEW9zqks5smjYngaJpZM4LXk4a .
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Vulnerator/Vulnerator/issues/72#issuecomment-332593671 , or mute the thread https://github.com/notifications/unsubscribe-auth/AQyCjAyQcCdgEBEJshZO7q6If4rMNXZyks5smoQDgaJpZM4LXk4a . https://github.com/notifications/beacon/AQyCjDZwirrBVofU17z9qWaWMl0HdCg4ks5smoQDgaJpZM4LXk4a.gif
Duh, the are no plugin It's for those.... The main categories are patches SI-2, generic configs such as as SSL strength CM-6 and obsolete software SA-22.
As a long time ISSM, I'd never make someone go though all of that, just for the sake of paperwork. The important thing is to find it and fix it.
On Sep 27, 2017 11:43, "Gerosolina" [email protected] wrote:
@ibjohn https://github.com/ibjohn Tracing to SCAP data from .xccdf files is not the problem. I can trace SCAP scans to RMF controls. But ACAS (nessus) scans only show plugin ID numbers and what vulnerabilities a system has. There is no way to trace a plugin ID number to an RMF control.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Vulnerator/Vulnerator/issues/72#issuecomment-332618021, or mute the thread https://github.com/notifications/unsubscribe-auth/AYw7-5BcZSnjCAdkZTq0cbqBR0BIGfAQks5smpdigaJpZM4LXk4a .
Unless the government directs NIST or DISA to allocate funds to perform the necessary mapping that's needed this isn't likely to happen anytime soon. Here's the plugins breakdown:
DoD Security Configurations It's highly unlikely that DISA is going to update their legacy STIGs and SRGs but these are still heavily used. Additionally the NIST 800-53 Rev 5 includes two additional security control families, Individual Participation (IP) and Privacy Authorization (PA), that could potentially require updates to all of the STIGs that currently contain CCI / 800-53 mapping. The million dollar question is are they going to review all of their currently pushed STIGs to reflect this in 2018 when Revision 5 is published?
Common Vulnerabilities and Exposures (CVE) NIST and MITRE publishes data feeds with known vulnerabilities via their data feed websites below. The public and vendors are free to pull this data and perform whatever mapping they'd like. There are currently 90,946 CVE's published. https://nvd.nist.gov/vuln/data-feeds https://cve.mitre.org/
Non-CVE / Non-STIG findings Nessus also scans using plugins that which directly fall in the CVE / DoD Security Configurations categories but should definitely be addressed. Their official website reports that "there are 90,691 total plugins that covering 40,679 unique CVE IDs and 26,257 unique Bugtraq IDs". So if I do a little math on just the CVE + Bugtraq ID's that means there's another 23,755 plugins that they've created from one source or another. https://www.tenable.com/plugins/index.php?view=all
So with all of that, I feel that we have the following choices: 1 - Group all Nessus findings as their SCA / AO have have reported 2 - Spend time after each scan to evaluate and map each finding to the 800-53 Rev 4/5 controls and use that data moving forward. (Tip, if you don't already know how to do this with the VLOOKUP function in Excel for updating a POAM you REALLY should look this up as it make short work out of large data sets.) 3 - Wait on the DoD or a Govt funded org to do this (crazier things have happened before) 4 - Wait around and hope that someone (maybe one of us) is so bored and underutilized at work that we do this and publish it on GitHub. But hey why you're at it, do me the favor of mapping the ISO, CIP, HIPPA, and PCI-DSS controls as I'm bound to come across these control requirements at some point in the near future too. ;-)
Rick
While the catch all from a generic standpoint could be SI-2 (FLAW REMEDIATION) or CM-6 (CONFIGURATION SETTINGS), I believe they actually extend beyond this. Take for instance the use of commercial product that someone has been limping along as they've deemed it "critical and unable to be replace at this time" which is still using SSL. This would fall under SI-2 and possibly CM-6 (if the product supported an approved version of TLS) but they would also be findings under IA-7, SA-4 (7)(b) and possibly others.
IA-7 (CRYPTOGRAPHIC MODULE AUTHENTICATION) - The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.
SA-4 (7) (ACQUISITION PROCESS | NIAP-APPROVED PROTECTION PROFILES) The organization: (a) Limits the use of commercially provided information assurance (IA) and IA-enabled information technology products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile for a specific technology type, if such a profile exists; and (b) Requires, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated.
From a due diligence standpoint, if you're going to use SI-2 and CM-6 as a catch-all you should annotate your reports to indicate that there are most likely additional controls that relate to an individual Nessus plugin that were not been fully vetted due to time constrains.
Rick
@rkotlarz @CyberSecDef @ibjohn @Gerosolina To address some of the above points:
- Vulnerator now pulls every cross reference that ACAS has for a plugin, be it a CVE, CPE, BID, IAVM, etc. Vulnerator also labels each cross reference using one of the above labels. All of this is designed to help end-users make as informed of a decision about their vulnerabilities as possible, whether that be in regards to NIST mapping or mitigation writing.
- Vulnerator also now provides the ability to map all vulnerabilities to NIST controls (finished it yesterday!). While manual mapping would have to occur after a plugin is first found, it would be a "one and done" deal, with those same mappings used for the rest of forever (or until they are changed, whichever comes first). This eliminates the need for having to do a VLOOKUP and provides the technology in a nifty GUI.
- Bonus: There will be a "Bulk Process" feature, allowing users to select as many controls as they want and apply NIST mappings to them en masse. This should help save loads of time, even when mapping to standard controls such as CM-6 or SI-2. Just select all ACAS related plugins, select the applicable controls, click the apply button, and Bob's your uncle.
While I can see the logic behind standardized mapping (definitely a time savings), I can also see the importance of taking the time to ensure that other controls are not impacted (accurate risk identification). Hopefully, Vulnerator will help with whichever path users decide to take.
Thank you all for the awesome conversation around this! If any of you would like to be added as "Members" of the Vulnerator organization, I am currently recruiting "user reps" :smile:
@amkuchta did you every address the issue of when you import SCAP data it does not show the items that were not reviewed by the automated scan. The items from the STIG checklist that the SCAP tool was not able to answer. I need this data so I can go back and manual review checks that the SCAP scan missed.
@Gerosolina It's still in development, but some of the major steps have been implemented:
- [x] Import the STIG Compilation Library or STIG that you need a checklist created for
- [ ] Generate CKL data within the app for the asset(s) in question
- [x] Import the corresponding SCAP data for said asset(s)
- [ ] Address the remaining controls
- Can be done manually or via the use of "stored" mitigations
- [ ] Export the CKL, as needed
- Data will always be stored in app, and Comments / Finding Details / Mitigations can be updated, as needed
- STIG data can be updated by importing new release libraries each quarter; the underlying data remains for updated checks, but a flag is set saying that they need review. New checks are added as they are released, and deleted checks are removed
STIG checks that have no data (either manual or SCAP) will be identified for easy review. Additionally, there are approval mechanisms in place now, ensuring that even SCAP-checked items get ISSO/M buy-in before being utilized in a package.
I don’t think SCAP was designed for what you are looking for.
A STIG (CKL) has hundreds of requirements that are manually checked. For this case study, let's assume ACME STIG has 200 requirements. Some of these requirements cannot be automated, like for instance "Is there a fire extinguisher near the system". A SCAP (XCCDF) is a subset of controls from a STIG that can be automatically scanned for. So, in this same case study let's say ACME SCAP has 150 requirements. The missing 50 from the SCAP can't automatically be imported into vulnerator and the resulting POAM/RAR because they literally do not exist in the SCAP result set.
That being said, I don't think you would need to reference a non-existent SCAP finding as 'open' in the resulting POAM/RAR. The proper place for the finding to be listed is in a CKL/STIG.
-----Original Message----- From: Gerosolina [mailto:[email protected]] Sent: Thursday, September 28, 2017 8:46 AM To: Vulnerator/Vulnerator Cc: Weber, Robert Jr CTR NSWCDD, B0I; Mention Subject: [Non-DoD Source] Re: [Vulnerator/Vulnerator] ACAS - NIST 800-53 control mapping (#72)
@amkuchta https://github.com/amkuchta did you every address the issue of when you import SCAP data it does not show the items that were not reviewed by the automated scan. The items from the STIG checklist that the SCAP tool was not able to answer. I need this data so I can go back and manual review checks that the SCAP scan missed.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Vulnerator/Vulnerator/issues/72#issuecomment-332824933 , or mute the thread https://github.com/notifications/unsubscribe-auth/AQyCjNKyica3zm-jFBm5OABQ9a3Xtvruks5sm5TqgaJpZM4LXk4a . https://github.com/notifications/beacon/AQyCjB-bufTVzpJF6DQa1qCo6wb3CAwIks5sm5TqgaJpZM4LXk4a.gif
@CyberSecDef I've addressed the issue of the SCAP not having all of the checks by allowing for the import of the full STIG library. As long as the library is imported into Vulnerator prior to the SCAP results being ingested, a complete CKL will be able to be generated taking into account the automated checks.
My goal is to eliminate the need for STIG Viewer altogether and to push CKL creation until the very last instant before package submission. This will help to prevent "outdated" test results and will also ensure that the POA&M / RAR / raw test results are always in alignment (read: traceable). It will also streamline workflows, especially if SAs and all members of the IA shop are given access to the database to allow them to work from the same data set (users can select which database they want to use at run time - either create a new one or select a pre-existing one. If a pre-existing file is stored in a share folder, anyone with sufficient access to said folder can point their instance of Vulnerator to it).
I can't wait to try this release out.
-----Original Message----- From: Alex Kuchta [mailto:[email protected]] Sent: Thursday, September 28, 2017 9:52 AM To: Vulnerator/Vulnerator Cc: Weber, Robert Jr CTR NSWCDD, B0I; Mention Subject: [Non-DoD Source] Re: [Vulnerator/Vulnerator] ACAS - NIST 800-53 control mapping (#72)
@CyberSecDef https://github.com/cybersecdef I've addressed the issue of the SCAP not having all of the checks by allowing for the import of the full STIG library. As long as the library is imported into Vulnerator prior to the SCAP results being ingested, a complete CKL will be able to be generated taking into account the automated checks.
My goal is to eliminate the need for STIG Viewer altogether and to push CKL creation until the very last instant before package submission. This will help to prevent "outdated" test results and will also ensure that the POA&M / RAR / raw test results are always in alignment (read: traceable). It will also streamline workflows, especially if SAs and all members of the IA shop are given access to the database to allow them to work from the same data set (users can select which database they want to use at run time - either create a new one or select a pre-existing one. If a pre-existing file is stored in a share folder, anyone with sufficient access to said folder can point their instance of Vulnerator to it).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Vulnerator/Vulnerator/issues/72#issuecomment-332842810 , or mute the thread https://github.com/notifications/unsubscribe-auth/AQyCjKC6ScLJbvLRl1hG-1BCo6D6A8GMks5sm6R_gaJpZM4LXk4a . https://github.com/notifications/beacon/AQyCjJdxwkwUoWHabYv1KWe3mwq9pTdnks5sm6R_gaJpZM4LXk4a.gif
@CyberSecDef I was hoping for a one stop shop so I would not have to use STIG view and vulnerator. Currently I have to load all SCAP results into STIG viewer then save a .CKL file and then import it into vulnerator so that I can see in the POAM the Not reviewed items.
@Moe0303 Could you please forward me your work thus far on the mappings between Nessus plugins to 800-53 controls and CCIs? Would definitely be most appreciative and I think as a Cybersecurity Professional myself, I may have some artifacts/templates that I can share with the Community/Team.
Thanks!
Anyone can forward me the mapping work? It would be really huge appreciated, and i would be happy to help you other whatever my skills let me do it 👍
