Improve CPE matching (again) and add SAR processing

[adamjanovsky]

Finnish research of CVEs and present the results.

The list below represents current state:

SARs and correlations

• [x] Double-check / verify the code for collecting SARs
• [ ] Remains to collect both SARs and EALs from Protection Profiles
• [ ] Rigorous leveling that adheres to CC standards should be in place (check for non-existant levels)
• [x] Rewrite Transformer will be a better fit, also for DependencyFinder.
• [x] Shall we also collect SARs from reports?
• [x] Docstrings to the Estimator, check that it adheres to guidelines: https://scikit-learn.org/stable/developers/develop.html
• [x] Fix tests
• [x] Evaluate if conditions for SAR computation are ok
• [x] Add table to derive SARs from security level

Note: Level checks on SARs were discarded due to older versions of common criteria. It is insufficient to rewrite the newest CC specification into the form of regular expressions that are enforced. We must count also for older versions of security assurance components. We should not mind false positive as long as we compute correlations and enforce large support.

Further improvement of CVE matching

• [x] Disable enhancing CPEs with CPEs only existing in CVE database (temporary fix for #173)
• [x] Implement string lemmatization with Spacy prior to matching
• [x] Evaluate improvement of the measures outlined above

[adamjanovsky]

Comment on recent CPE matching advances

I did four things:

• Standardize version names in product names
• lower required match threshold from 100 to 90
• Forbid enhancing CPE datasets with CPEs that appear only in CVE database
• lemmatize product names, see below

Implementing lemmatization brings certificate product names into canonical form which simplifies the comparison with CPE strings. It would be time consuming to standardize all CPEs but I assume that they are mostly in the standard form. This is surely not the case for certificate names. Consider

"Infineon Security Controller M7892 B11 with optional RSA2048/4096 v1.02.013, EC v1.02.013, SHA-2 v1.01, SCL v2.02.012, Base v1.02.013, and Toolbox v1.02.013 libraries and with specific IC dedicated software (firmware)"

Direct comparison with CPE "Infineon RSA Library 1.02.013" yields 72 similarity score (due to libraries and library mismatch). We treat this by lemmatization that returns

'infineon security controller m7892 b11 with optional rsa2048/4096 1.02.013 , ec 1.02.013 , sha-2 1.01 , scl 2.02.012 , base 1.02.013 , and toolbox 1.02.013 library and with specific ic dedicated software ( firmware )'

that gets ~92 similarity score.

All improvements yield the following results in comparison to previous version:

• Precision drop: 1%
• New certificates with >0 CPE match: 31
• Total number of new CPE matches: 588
• Not being too benevolent (see #173)
• This evaluation was performed on a validation dataset, we can thus expect approx. 60 new certs with CPEs.

[adamjanovsky]

@J08nY, prior to running sec-certs, a Spacy language model must be downloaded with python -m spacy download en_core_web_sm.

[adamjanovsky]

@J08nY I implemented some SAR inference and EAL cleaning. May be of interest for you:

• CommonCriteriaCert now implements property EAL that returns its EAL level (until now unprocessed in security_level)
• CommonCriteriaCert now implements actual_sars property that lists all SARs. There are two sources of SARs:
  1. SARs implied by EAL see https://github.com/crocs-muni/sec-certs/blob/d10334b7aaab83c8aa5e0897c93c6465c85d4874/sec_certs/cert_rules.py#L8-L176
  2. SARs extracted by SAR_transformer (for procedure, see #200)
• The CCHeuristics object now holds extracted_sars which basically is a list of SARs excluding EAL-implied SARs.

[adamjanovsky]

@J08nY merged, feel free to update the web. Note the two comments above.