added nvd_cve analyzer closes (#2245)

[spoiicy]

closes #2245

Description

Added NIST CVE analyzer which fetches the details of supplied CVE id.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist

• I have read and understood the rules about how to Contribute to this project
• The pull request is for the branch develop
• A new plugin (analyzer, connector, visualizer, playbook, pivot or ingestor) was added or changed, in which case:
  • I strictly followed the documentation "How to create a Plugin"
  • Usage file was updated.
  • [] Advanced-Usage was updated (in case the plugin provides additional optional configuration).
  • I have dumped the configuration from Django Admin using the dumpplugin command and added it in the project as a data migration. ("How to share a plugin with the community")
  • If a File analyzer was added and it supports a mimetype which is not already supported, you added a sample of that type inside the archive test_files.zip and you added the default tests for that mimetype in test_classes.py.
  • If you created a new analyzer and it is free (does not require any API key), please add it in the FREE_TO_USE_ANALYZERS playbook by following this guide.
  • Check if it could make sense to add that analyzer/connector to other freely available playbooks.
  • I have provided the resulting raw JSON of a finished analysis and a screenshot of the results.
  • If the plugin interacts with an external service, I have created an attribute called precisely url that contains this information. This is required for Health Checks.
  • If the plugin requires mocked testing, _monkeypatch() was used in its class to apply the necessary decorators.
  • I have added that raw JSON sample to the MockUpResponse of the _monkeypatch() method. This serves us to provide a valid sample for testing.
• If external libraries/packages with restrictive licenses were used, they were added in the Legal Notice section.
• Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• I have added tests for the feature/bug I solved (see tests folder). All the tests (new and old ones) gave 0 errors.
• If changes were made to an existing model/serializer/view, the docs were updated and regenerated (check CONTRIBUTE.md).
• If the GUI has been modified:
  • I have a provided a screenshot of the result in the PR.
  • I have created new frontend tests for the new component or updated existing ones.
• After you had submitted the PR, if DeepSource, Django Doctors or other third-party linters have triggered any alerts during the CI checks, I have solved those alerts.

Important Rules

• If you miss to compile the Checklist properly, your PR won't be reviewed by the maintainers.
• Everytime you make changes to the PR and you think the work is done, you should explicitly ask for a review. After being reviewed and received a "change request", you should explicitly ask for a review again once you have made the requested changes.

Screenshot

JSON Report

job#16_report.json

[spoiicy]

@mlodic I've updated the Usage.md with the NIST CVE analyzer details.
intelowlproject/docs#10

[mlodic]

considering that only CVE numbers are accepted, I would add a check in the code about the correctness of the CVE (a regex). Could you add it?

[spoiicy]

considering that only CVE numbers are accepted, I would add a check in the code about the correctness of the CVE (a regex). Could you add it?

Sure, why not. I'll add it promptly.

[spoiicy]

@mlodic should I add a testcase of valid CVE since for generic analyzers observable_name is set to [email protected] or should I create a validate_cve_format() function and monkeypatch it? what do you suggest

[mlodic]

can you please pull from develop and update the migration numbers. This can happen while other people are working on the project and their PR are merged earlier.

About your question: it would be great if you could add a new test for this analyzer only and with the correct and incorrect input + yes, use a validate_cve_format function and patch it to have the "classic" test working

[spoiicy]

can you please pull from develop and update the migration numbers. This can happen while other people are working on the project and their PR are merged earlier.

About your question: it would be great if you could add a new test for this analyzer only and with the correct and incorrect input + yes, use a validate_cve_format function and patch it to have the "classic" test working

Could you let me know if there is any information on where to add the tests, how the tests function. I'd gone through the documentation but there was little info regarding this. This would help me in creating the tests for this analyzer.

[mlodic]

to create a new specific test you can copy how was done for the recent file analyzers tests that were added here. You can create a new folder observable_analyzers and add your specific test for that analyzer.

About the "classic" tests: in test_classes.py you can find some tests that are meant to automatically test every new analyzer without having to write manually basic tests for each new added analyzers. For this case, we should add an exception cause the tests are not passing. The easiest thing would be to check in the analyer code whether the code is running during tests (you can do this by check the setting STAGE) and, in that case, avoiding the CVE format check you just added.
This is a trick but considering that you are already adding new custom tests is not a problem. What do you think about?

[spoiicy]

to create a new specific test you can copy how was done for the recent file analyzers tests that were added here. You can create a new folder observable_analyzers and add your specific test for that analyzer.

About the "classic" tests: in test_classes.py you can find some tests that are meant to automatically test every new analyzer without having to write manually basic tests for each new added analyzers. For this case, we should add an exception cause the tests are not passing. The easiest thing would be to check in the analyer code whether the code is running during tests (you can do this by check the setting STAGE) and, in that case, avoiding the CVE format check you just added. This is a trick but considering that you are already adding new custom tests is not a problem. What do you think about?

Though skipping the check would reduce my work but I think I should go with adding the tests since that will be helpful in future as well.
I'll try to understand how the tests are written and will understand how they are working and then will implement them. I hope that works and we are not over-engineering this. ⊂(◉‿◉)つ

[spoiicy]

@mlodic hope this is sufficient, let me know in case you want any changes to be made. :)

[mlodic]

great! merged!