From 34de9ca848cce92bf3bdbe4a1d9e05ff9e794de3 Mon Sep 17 00:00:00 2001 From: J08nY Date: Fri, 19 Jul 2024 14:49:58 +0200 Subject: Temporarily disable broken CC USA scheme test. --- tests/cc/test_cc_schemes.py | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/cc/test_cc_schemes.py b/tests/cc/test_cc_schemes.py index a9e2105c..5ae5a180 100644 --- a/tests/cc/test_cc_schemes.py +++ b/tests/cc/test_cc_schemes.py @@ -178,6 +178,7 @@ def test_turkey(): @pytest.mark.xfail(reason="May fail due to server errors.", raises=RequestException) def test_usa(): + pytest.skip() certified = CCSchemes.get_usa_certified() assert len(certified) != 0 assert absolute_urls(certified) -- cgit v1.3.1 From e42f5ca573a971af80c332453341e7ff84c6b09b Mon Sep 17 00:00:00 2001 From: J08nY Date: Fri, 19 Jul 2024 16:00:03 +0200 Subject: Move to new dgst algorithm for CC. --- src/sec_certs/dataset/cc.py | 23 +- src/sec_certs/sample/cc.py | 58 +- src/sec_certs/utils/sanitization.py | 9 + tests/cc/test_cc_analysis.py | 8 +- tests/cc/test_cc_dataset.py | 44 +- tests/cc/test_cc_maintenance_updates.py | 4 +- .../certs/reports/pdf/ebd276cca70fd723.pdf | Bin 1174271 -> 0 bytes .../certs/reports/pdf/ed91ff3e658457fd.pdf | Bin 0 -> 1174271 bytes .../certs/reports/txt/ebd276cca70fd723.txt | 1068 ---------- .../certs/reports/txt/ed91ff3e658457fd.txt | 1068 ++++++++++ .../certs/targets/pdf/ebd276cca70fd723.pdf | Bin 615034 -> 0 bytes .../certs/targets/pdf/ed91ff3e658457fd.pdf | Bin 0 -> 615034 bytes .../certs/targets/txt/ebd276cca70fd723.txt | 2168 -------------------- .../certs/targets/txt/ed91ff3e658457fd.txt | 2168 ++++++++++++++++++++ tests/data/cc/analysis/reference_dataset.json | 6 +- .../analysis/transitive_vulnerability_dataset.json | 6 +- tests/data/cc/analysis/vulnerable_dataset.json | 4 +- tests/data/cc/certificate/fictional_cert.json | 2 +- .../maintenances/maintenance_updates.json | 4 +- tests/data/cc/dataset/report_309ac2fd7f2dcf17.txt | 481 ----- tests/data/cc/dataset/report_e3dcf91ef38ddbf0.txt | 481 +++++ tests/data/cc/dataset/target_309ac2fd7f2dcf17.txt | 1497 -------------- tests/data/cc/dataset/target_e3dcf91ef38ddbf0.txt | 1497 ++++++++++++++ tests/data/cc/dataset/toy_dataset.json | 6 +- 24 files changed, 5320 insertions(+), 5282 deletions(-) delete mode 100644 tests/data/cc/analysis/certs/reports/pdf/ebd276cca70fd723.pdf create mode 100644 tests/data/cc/analysis/certs/reports/pdf/ed91ff3e658457fd.pdf delete mode 100644 tests/data/cc/analysis/certs/reports/txt/ebd276cca70fd723.txt create mode 100644 tests/data/cc/analysis/certs/reports/txt/ed91ff3e658457fd.txt delete mode 100644 tests/data/cc/analysis/certs/targets/pdf/ebd276cca70fd723.pdf create mode 100644 tests/data/cc/analysis/certs/targets/pdf/ed91ff3e658457fd.pdf delete mode 100644 tests/data/cc/analysis/certs/targets/txt/ebd276cca70fd723.txt create mode 100644 tests/data/cc/analysis/certs/targets/txt/ed91ff3e658457fd.txt delete mode 100644 tests/data/cc/dataset/report_309ac2fd7f2dcf17.txt create mode 100644 tests/data/cc/dataset/report_e3dcf91ef38ddbf0.txt delete mode 100644 tests/data/cc/dataset/target_309ac2fd7f2dcf17.txt create mode 100644 tests/data/cc/dataset/target_e3dcf91ef38ddbf0.txt diff --git a/src/sec_certs/dataset/cc.py b/src/sec_certs/dataset/cc.py index 8e6ecebb..ebffd912 100644 --- a/src/sec_certs/dataset/cc.py +++ b/src/sec_certs/dataset/cc.py @@ -34,7 +34,7 @@ from sec_certs.sample.cc_maintenance_update import CCMaintenanceUpdate from sec_certs.sample.cc_scheme import EntryType from sec_certs.sample.protection_profile import ProtectionProfile from sec_certs.serialization.json import ComplexSerializableType, serialize -from sec_certs.utils import helpers +from sec_certs.utils import helpers, sanitization from sec_certs.utils import parallel_processing as cert_processing from sec_certs.utils.profiling import staged @@ -368,7 +368,14 @@ class CCDataset(Dataset[CCCertificate, CCAuxiliaryDatasets], ComplexSerializable return CCDataset.BASE_URL + relative_path def _get_primary_key_str(row: Tag): - return row["category"] + row["cert_name"] + row["report_link"] + return "|".join( + [ + row["category"], + row["cert_name"], + sanitization.sanitize_link_fname(row["report_link"]) or "None", + sanitization.sanitize_link_fname(row["st_link"]) or "None", + ] + ) cert_status = "active" if "active" in str(file) else "archived" @@ -408,11 +415,15 @@ class CCDataset(Dataset[CCCertificate, CCAuxiliaryDatasets], ComplexSerializable df_base = df.loc[~df.is_maintenance].copy() df_main = df.loc[df.is_maintenance].copy() - df_base.report_link = df_base.report_link.map(map_ip_to_hostname) - df_base.st_link = df_base.st_link.map(map_ip_to_hostname) + df_base.report_link = df_base.report_link.map(map_ip_to_hostname).map(sanitization.sanitize_link) + df_base.st_link = df_base.st_link.map(map_ip_to_hostname).map(sanitization.sanitize_link) - df_main.maintenance_report_link = df_main.maintenance_report_link.map(map_ip_to_hostname) - df_main.maintenance_st_link = df_main.maintenance_st_link.map(map_ip_to_hostname) + df_main.maintenance_report_link = df_main.maintenance_report_link.map(map_ip_to_hostname).map( + sanitization.sanitize_link + ) + df_main.maintenance_st_link = df_main.maintenance_st_link.map(map_ip_to_hostname).map( + sanitization.sanitize_link + ) n_all = len(df_base) n_deduplicated = len(df_base.drop_duplicates(subset=["dgst"])) diff --git a/src/sec_certs/sample/cc.py b/src/sec_certs/sample/cc.py index 9f8ba2bd..5354ab3b 100644 --- a/src/sec_certs/sample/cc.py +++ b/src/sec_certs/sample/cc.py @@ -15,7 +15,6 @@ from bs4 import Tag import sec_certs.utils.extract import sec_certs.utils.pdf -import sec_certs.utils.sanitization from sec_certs import constants from sec_certs.cert_rules import SARS_IMPLIED_FROM_EAL, cc_rules, rules, security_level_csv_scan from sec_certs.configuration import config @@ -27,7 +26,7 @@ from sec_certs.sample.protection_profile import ProtectionProfile from sec_certs.sample.sar import SAR from sec_certs.serialization.json import ComplexSerializableType from sec_certs.serialization.pandas import PandasSerializableType -from sec_certs.utils import helpers +from sec_certs.utils import helpers, sanitization from sec_certs.utils.extract import normalize_match_string, scheme_frontpage_functions @@ -57,16 +56,10 @@ class CCCertificate( maintenance_st_link: str | None def __post_init__(self): - super().__setattr__( - "maintenance_report_link", sec_certs.utils.sanitization.sanitize_cc_link(self.maintenance_report_link) - ) - super().__setattr__( - "maintenance_st_link", sec_certs.utils.sanitization.sanitize_cc_link(self.maintenance_st_link) - ) - super().__setattr__( - "maintenance_title", sec_certs.utils.sanitization.sanitize_string(self.maintenance_title) - ) - super().__setattr__("maintenance_date", sec_certs.utils.sanitization.sanitize_date(self.maintenance_date)) + super().__setattr__("maintenance_report_link", sanitization.sanitize_link(self.maintenance_report_link)) + super().__setattr__("maintenance_st_link", sanitization.sanitize_link(self.maintenance_st_link)) + super().__setattr__("maintenance_title", sanitization.sanitize_string(self.maintenance_title)) + super().__setattr__("maintenance_date", sanitization.sanitize_date(self.maintenance_date)) @classmethod def from_dict(cls, dct: dict) -> CCCertificate.MaintenanceReport: @@ -420,20 +413,20 @@ class CCCertificate( self.status = status self.category = category - self.name = sec_certs.utils.sanitization.sanitize_string(name) + self.name = sanitization.sanitize_string(name) self.manufacturer = None if manufacturer: - self.manufacturer = sec_certs.utils.sanitization.sanitize_string(manufacturer) + self.manufacturer = sanitization.sanitize_string(manufacturer) self.scheme = scheme - self.security_level = sec_certs.utils.sanitization.sanitize_security_levels(security_level) - self.not_valid_before = sec_certs.utils.sanitization.sanitize_date(not_valid_before) - self.not_valid_after = sec_certs.utils.sanitization.sanitize_date(not_valid_after) - self.report_link = sec_certs.utils.sanitization.sanitize_cc_link(report_link) - self.st_link = sec_certs.utils.sanitization.sanitize_cc_link(st_link) - self.cert_link = sec_certs.utils.sanitization.sanitize_cc_link(cert_link) - self.manufacturer_web = sec_certs.utils.sanitization.sanitize_link(manufacturer_web) + self.security_level = sanitization.sanitize_security_levels(security_level) + self.not_valid_before = sanitization.sanitize_date(not_valid_before) + self.not_valid_after = sanitization.sanitize_date(not_valid_after) + self.report_link = sanitization.sanitize_link(report_link) + self.st_link = sanitization.sanitize_link(st_link) + self.cert_link = sanitization.sanitize_link(cert_link) + self.manufacturer_web = sanitization.sanitize_link(manufacturer_web) self.protection_profiles = protection_profiles self.maintenance_updates = maintenance_updates self.state = state if state else self.InternalState() @@ -445,6 +438,29 @@ class CCCertificate( """ Computes the primary key of the sample using first 16 bytes of SHA-256 digest """ + if not (self.name is not None and self.category is not None): + raise RuntimeError("Certificate digest can't be computed, because information is missing.") + return helpers.get_first_16_bytes_sha256( + "|".join( + [ + self.category, + self.name, + sanitization.sanitize_link_fname(self.report_link) or "None", + sanitization.sanitize_link_fname(self.st_link) or "None", + ] + ) + ) + + @property + def old_dgst(self) -> str: + if not (self.name is not None and self.report_link is not None and self.category is not None): + raise RuntimeError("Certificate digest can't be computed, because information is missing.") + return helpers.get_first_16_bytes_sha256( + self.category + self.name + sanitization.sanitize_cc_link(self.report_link) # type: ignore + ) + + @property + def older_dgst(self) -> str: if not (self.name is not None and self.report_link is not None and self.category is not None): raise RuntimeError("Certificate digest can't be computed, because information is missing.") return helpers.get_first_16_bytes_sha256(self.category + self.name + self.report_link) diff --git a/src/sec_certs/utils/sanitization.py b/src/sec_certs/utils/sanitization.py index fd477746..4a7326eb 100644 --- a/src/sec_certs/utils/sanitization.py +++ b/src/sec_certs/utils/sanitization.py @@ -3,6 +3,8 @@ from __future__ import annotations import html import logging from datetime import date +from pathlib import Path +from urllib.parse import urlparse import numpy as np import pandas as pd @@ -23,6 +25,13 @@ def sanitize_link(record: str | None) -> str | None: return record.replace(":443", "").replace(" ", "%20").replace("http://", "https://") +def sanitize_link_fname(record: str | None) -> str | None: + if not record: + return None + parsed = urlparse(record) + return Path(parsed.path).name + + def sanitize_cc_link(record: str | None) -> str | None: record = sanitize_link(record) if not record: diff --git a/tests/cc/test_cc_analysis.py b/tests/cc/test_cc_analysis.py index 3984a72e..ce83d705 100644 --- a/tests/cc/test_cc_analysis.py +++ b/tests/cc/test_cc_analysis.py @@ -53,7 +53,7 @@ def transitive_vulnerability_dataset(analysis_data_dir) -> CCDataset: @pytest.fixture def random_certificate(processed_cc_dset: CCDataset) -> CCCertificate: - return processed_cc_dset["ebd276cca70fd723"] + return processed_cc_dset["ed91ff3e658457fd"] def test_match_cpe(random_certificate: CCCertificate): @@ -162,7 +162,7 @@ def test_single_record_references_heuristics(random_certificate: CCCertificate): def test_reference_dataset(reference_dataset: CCDataset): reference_dataset._compute_references() - test_cert = reference_dataset["692e91451741ef49"] + test_cert = reference_dataset["d1b238729b25d745"] assert test_cert.heuristics.report_references.directly_referenced_by == {"BSI-DSZ-CC-0370-2006"} assert test_cert.heuristics.report_references.indirectly_referenced_by == { @@ -175,12 +175,12 @@ def test_reference_dataset(reference_dataset: CCDataset): def test_direct_transitive_vulnerability_dataset(transitive_vulnerability_dataset: CCDataset): transitive_vulnerability_dataset._compute_transitive_vulnerabilities() - assert transitive_vulnerability_dataset["d0705c9e6fbaeba3"].heuristics.direct_transitive_cves == {"CVE-2013-5385"} + assert transitive_vulnerability_dataset["11f77cb31b931a57"].heuristics.direct_transitive_cves == {"CVE-2013-5385"} def test_indirect_transitive_vulnerability_dataset(transitive_vulnerability_dataset: CCDataset): transitive_vulnerability_dataset._compute_transitive_vulnerabilities() - assert transitive_vulnerability_dataset["d0705c9e6fbaeba3"].heuristics.indirect_transitive_cves == {"CVE-2013-5385"} + assert transitive_vulnerability_dataset["11f77cb31b931a57"].heuristics.indirect_transitive_cves == {"CVE-2013-5385"} def test_sar_object(): diff --git a/tests/cc/test_cc_dataset.py b/tests/cc/test_cc_dataset.py index 9d1e4022..bc1433aa 100644 --- a/tests/cc/test_cc_dataset.py +++ b/tests/cc/test_cc_dataset.py @@ -11,22 +11,24 @@ from sec_certs.sample.cc import CCCertificate def test_download_and_convert_pdfs(toy_dataset: CCDataset, data_dir: Path): + for cert in toy_dataset: + print(cert.dgst, cert.old_dgst, cert.older_dgst) template_report_pdf_hashes = { - "309ac2fd7f2dcf17": "774c41fbba980191ca40ae610b2f61484c5997417b3325b6fd68b345173bde52", - "8cf86948f02f047d": "533a5995ef8b736cc48cfda30e8aafec77d285511471e0e5a9e8007c8750203a", - "8a5e6bcda602920c": "e277151e4b279085cd3041ce914ffb3942b43e5ace911c557ad6b8ed764a4ece", + "e3dcf91ef38ddbf0": "774c41fbba980191ca40ae610b2f61484c5997417b3325b6fd68b345173bde52", + "ed7611868f0f9d97": "533a5995ef8b736cc48cfda30e8aafec77d285511471e0e5a9e8007c8750203a", + "8f08cacb49a742fb": "e277151e4b279085cd3041ce914ffb3942b43e5ace911c557ad6b8ed764a4ece", } template_st_pdf_hashes = { - "309ac2fd7f2dcf17": "b9a45995d9e40b2515506bbf5945e806ef021861820426c6d0a6a074090b47a9", - "8cf86948f02f047d": "3c8614338899d956e9e56f1aa88d90e37df86f3310b875d9d14ec0f71e4759be", - "8a5e6bcda602920c": "fcee91f09bb72a6526a1f94d0ab754a6db3fbe3ba5773cd372df19788bb25292", + "e3dcf91ef38ddbf0": "b9a45995d9e40b2515506bbf5945e806ef021861820426c6d0a6a074090b47a9", + "ed7611868f0f9d97": "3c8614338899d956e9e56f1aa88d90e37df86f3310b875d9d14ec0f71e4759be", + "8f08cacb49a742fb": "fcee91f09bb72a6526a1f94d0ab754a6db3fbe3ba5773cd372df19788bb25292", } template_cert_pdf_hashes = { - "309ac2fd7f2dcf17": "9d38bca310c4d349cc39471e0b75d939cc275db9a75b07b8a365d719cfbedcc5", - "8cf86948f02f047d": None, - "8a5e6bcda602920c": "4ba78f26f505819183256ca5a6b404fa90c750fe160c41791e4c400f64e2f6d5", + "e3dcf91ef38ddbf0": "9d38bca310c4d349cc39471e0b75d939cc275db9a75b07b8a365d719cfbedcc5", + "ed7611868f0f9d97": None, + "8f08cacb49a742fb": "4ba78f26f505819183256ca5a6b404fa90c750fe160c41791e4c400f64e2f6d5", } with TemporaryDirectory() as td: @@ -34,14 +36,14 @@ def test_download_and_convert_pdfs(toy_dataset: CCDataset, data_dir: Path): toy_dataset.download_all_artifacts() if not ( - toy_dataset["309ac2fd7f2dcf17"].state.report.download_ok - or toy_dataset["309ac2fd7f2dcf17"].state.st.download_ok - or toy_dataset["309ac2fd7f2dcf17"].state.cert.download_ok - or toy_dataset["8cf86948f02f047d"].state.report.download_ok - or toy_dataset["8cf86948f02f047d"].state.st.download_ok - or toy_dataset["8a5e6bcda602920c"].state.report.download_ok - or toy_dataset["8a5e6bcda602920c"].state.st.download_ok - or toy_dataset["8a5e6bcda602920c"].state.cert.download_ok + toy_dataset["e3dcf91ef38ddbf0"].state.report.download_ok + or toy_dataset["e3dcf91ef38ddbf0"].state.st.download_ok + or toy_dataset["e3dcf91ef38ddbf0"].state.cert.download_ok + or toy_dataset["ed7611868f0f9d97"].state.report.download_ok + or toy_dataset["ed7611868f0f9d97"].state.st.download_ok + or toy_dataset["8f08cacb49a742fb"].state.report.download_ok + or toy_dataset["8f08cacb49a742fb"].state.st.download_ok + or toy_dataset["8f08cacb49a742fb"].state.cert.download_ok ): pytest.xfail(reason="Fail due to error during download") @@ -60,15 +62,15 @@ def test_download_and_convert_pdfs(toy_dataset: CCDataset, data_dir: Path): if cert.cert_link: assert cert.state.cert.txt_path.exists() - template_report_txt_path = data_dir / "report_309ac2fd7f2dcf17.txt" - template_st_txt_path = data_dir / "target_309ac2fd7f2dcf17.txt" + template_report_txt_path = data_dir / "report_e3dcf91ef38ddbf0.txt" + template_st_txt_path = data_dir / "target_e3dcf91ef38ddbf0.txt" assert ( - abs(toy_dataset["309ac2fd7f2dcf17"].state.st.txt_path.stat().st_size - template_st_txt_path.stat().st_size) + abs(toy_dataset["e3dcf91ef38ddbf0"].state.st.txt_path.stat().st_size - template_st_txt_path.stat().st_size) < 1000 ) assert ( abs( - toy_dataset["309ac2fd7f2dcf17"].state.report.txt_path.stat().st_size + toy_dataset["e3dcf91ef38ddbf0"].state.report.txt_path.stat().st_size - template_report_txt_path.stat().st_size ) < 1000 diff --git a/tests/cc/test_cc_maintenance_updates.py b/tests/cc/test_cc_maintenance_updates.py index c5054002..9c89c748 100644 --- a/tests/cc/test_cc_maintenance_updates.py +++ b/tests/cc/test_cc_maintenance_updates.py @@ -41,7 +41,7 @@ def test_methods_not_meant_to_be_implemented(): def test_download_artifacts(mu_dset: CCDatasetMaintenanceUpdates): # Conversion and extraction is identical to CC, will not test. mu_dset.download_all_artifacts() - mu = mu_dset["cert_8a5e6bcda602920c_update_559ed93dd80320b5"] + mu = mu_dset["cert_8f08cacb49a742fb_update_559ed93dd80320b5"] if not (mu.state.report.download_ok or mu.state.st.download_ok): pytest.xfail(reason="Fail due to error on CC server.") @@ -82,4 +82,4 @@ def test_from_web(): dset = CCDatasetMaintenanceUpdates.from_web_latest() assert dset is not None assert len(dset) >= 492 # Contents as of November 2022, maintenances should not disappear - assert "cert_8a5e6bcda602920c_update_559ed93dd80320b5" in dset # random cert verified to be present + assert "cert_8f08cacb49a742fb_update_559ed93dd80320b5" in dset # random cert verified to be present diff --git a/tests/data/cc/analysis/certs/reports/pdf/ebd276cca70fd723.pdf b/tests/data/cc/analysis/certs/reports/pdf/ebd276cca70fd723.pdf deleted file mode 100644 index faccbd64..00000000 Binary files a/tests/data/cc/analysis/certs/reports/pdf/ebd276cca70fd723.pdf and /dev/null differ diff --git a/tests/data/cc/analysis/certs/reports/pdf/ed91ff3e658457fd.pdf b/tests/data/cc/analysis/certs/reports/pdf/ed91ff3e658457fd.pdf new file mode 100644 index 00000000..faccbd64 Binary files /dev/null and b/tests/data/cc/analysis/certs/reports/pdf/ed91ff3e658457fd.pdf differ diff --git a/tests/data/cc/analysis/certs/reports/txt/ebd276cca70fd723.txt b/tests/data/cc/analysis/certs/reports/txt/ebd276cca70fd723.txt deleted file mode 100644 index ed1ca246..00000000 --- a/tests/data/cc/analysis/certs/reports/txt/ebd276cca70fd723.txt +++ /dev/null @@ -1,1068 +0,0 @@ -BSI-DSZ-CC-0683-2014 -for -IBM Security Access Manager for Enterprise -Single Sign-On, Version 8.2 -from -IBM Corporation - BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn -Phone +49 (0)228 99 9582-0, Fax +49 (0)228 9582-5477, Infoline +49 (0)228 99 9582-111 -Certification Report V1.0 CC-Zert-327 V5.02 - BSI-DSZ-CC-0683-2014 -Access Control System -IBM Security Access Manager for Enterprise Single Sign-On -Version 8.2 -from: IBM Corporation -PP Conformance: None -Functionality: Product specific Security Target -Common Criteria Part 2 conformant -Assurance: Common Criteria Part 3 conformant -EAL 3 augmented by ALC_FLR.1 -SOGIS -Recognition Agreement -The IT Product identified in this certificate has been evaluated at an approved evaluation -facility using the Common Methodology for IT Security Evaluation (CEM), Version 3.1 for -conformance to the Common Criteria for IT Security Evaluation (CC), Version 3.1. CC and -CEM are also published as ISO/IEC 15408 and ISO/IEC 18045. -This certificate applies only to the specific version and release of the product in its -evaluated configuration and in conjunction with the complete Certification Report. -The evaluation has been conducted in accordance with the provisions of the certification -scheme of the German Federal Office for Information Security (BSI) and the conclusions -of the evaluation facility in the evaluation technical report are consistent with the evidence -adduced. -This certificate is not an endorsement of the IT Product by the Federal Office for -Information Security or any other organisation that recognises or gives effect to this -certificate, and no warranty of the IT Product by the Federal Office for Information -Security or any other organisation that recognises or gives effect to this certificate, is -either expressed or implied. -Common Criteria -Recognition Arrangement -Bonn, 5 December 2014 -For the Federal Office for Information Security -Bernd Kowalski L.S. -Head of Department -Bundesamt für Sicherheit in der Informationstechnik -Godesberger Allee 185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn -Phone +49 (0)228 99 9582-0 - Fax +49 (0)228 9582-5477 - Infoline +49 (0)228 99 9582-111 - Certification Report BSI-DSZ-CC-0683-2014 -This page is intentionally left blank. -6 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -Preliminary Remarks -Under the BSIG1 -Act, the Federal Office for Information Security (BSI) has the task of -issuing certificates for information technology products. -Certification of a product is carried out on the instigation of the vendor or a distributor, -hereinafter called the sponsor. -A part of the procedure is the technical examination (evaluation) of the product according -to the security criteria published by the BSI or generally recognised security criteria. -The evaluation is normally carried out by an evaluation facility recognised by the BSI or by -BSI itself. -The result of the certification procedure is the present Certification Report. This report -contains among others the certificate (summarised assessment) and the detailed -Certification Results. -The Certification Results contain the technical description of the security functionality of -the certified product, the details of the evaluation (strength and weaknesses) and -instructions for the user. -1 -Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August 2009, -Bundesgesetzblatt I p. 2821 -5 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -Contents -A Certification.........................................................................................................................7 -1 Specifications of the Certification Procedure..................................................................7 -2 Recognition Agreements.................................................................................................7 -3 Performance of Evaluation and Certification...................................................................8 -4 Validity of the Certification Result....................................................................................9 -5 Publication.......................................................................................................................9 -B Certification Results..........................................................................................................11 -1 Executive Summary......................................................................................................12 -2 Identification of the TOE................................................................................................13 -3 Security Policy...............................................................................................................14 -4 Assumptions and Clarification of Scope........................................................................15 -5 Architectural Information................................................................................................15 -6 Documentation..............................................................................................................16 -7 IT Product Testing..........................................................................................................16 -8 Evaluated Configuration................................................................................................19 -9 Results of the Evaluation...............................................................................................20 -10 Obligations and Notes for the Usage of the TOE........................................................20 -11 Security Target.............................................................................................................20 -12 Definitions....................................................................................................................21 -13 Bibliography.................................................................................................................23 -C Excerpts from the Criteria.................................................................................................25 -CC Part 1:........................................................................................................................25 -CC Part 3:........................................................................................................................26 -D Annexes............................................................................................................................33 -6 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -A Certification -1 Specifications of the Certification Procedure -The certification body conducts the procedure according to the criteria laid down in the -following: -● Act on the Federal Office for Information Security2 -● BSI Certification Ordinance3 -● BSI Schedule of Costs4 -● Special decrees issued by the Bundesministerium des Innern (Federal Ministry of the -Interior) -● DIN EN ISO/IEC 17065 standard -● BSI certification: Technical information on the IT security certification, Procedural -Description (BSI 7138) [3] -● BSI certification: Requirements regarding the Evaluation Facility (BSI 7125) [3] -● Common Criteria for IT Security Evaluation (CC), Version 3.15 -[1] also published as -ISO/IEC 15408. -● Common Methodology for IT Security Evaluation (CEM), Version 3.1 [2] also published -as ISO/IEC 18045. -● BSI certification: Application Notes and Interpretation of the Scheme (AIS) [4] -2 Recognition Agreements -In order to avoid multiple certification of the same product in different countries a mutual -recognition of IT security certificates - as far as such certificates are based on ITSEC or -CC - under certain conditions was agreed. -2.1 European Recognition of ITSEC/CC – Certificates (SOGIS-MRA) -The SOGIS-Mutual Recognition Agreement (SOGIS-MRA) Version 3 became effective in -April 2010. It defines the recognition of certificates for IT-Products at a basic recognition -level and in addition at higher recognition levels for IT-Products related to certain technical -domains only. -The basic recognition level includes Common Criteria (CC) Evaluation Assurance Levels -EAL 1 to EAL 4 and ITSEC Evaluation Assurance Levels E1 to E3 (basic). For higher -recognition levels the technical domain Smart card and similar Devices has been defined. -2 -Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August 2009, -Bundesgesetzblatt I p. 2821 -3 -Ordinance on the Procedure for Issuance of a Certificate by the Federal Office for Information Security -(BSI-Zertifizierungsverordnung, BSIZertV) of 07 July 1992, Bundesgesetzblatt I p. 1230 -4 -Schedule of Cost for Official Procedures of the Bundesamt für Sicherheit in der Informationstechnik -(BSI-Kostenverordnung, BSI-KostV) of 03 March 2005, Bundesgesetzblatt I p. 519 -5 -Proclamation of the Bundesministerium des Innern of 12 February 2007 in the Bundesanzeiger dated -23 February 2007, p. 3730 -7 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -It includes assurance levels beyond EAL 4 resp. E3 (basic). In addition, certificates issued -for Protection Profiles based on Common Criteria are part of the recognition agreement. -As of September 2011 the new agreement has been signed by the national bodies of -Austria, Finland, France, Germany, Italy, The Netherlands, Norway, Spain, Sweden and -the United Kingdom. Details on recognition and the history of the agreement can be found -at https://www.bsi.bund.de/zertifizierung. -The SOGIS-MRA logo printed on the certificate indicates that it is recognised under the -terms of this agreement by the nations listed above. -This certificate is recognized under SOGIS-MRA for all assurance components selected. -2.2 International Recognition of CC – Certificates (CCRA) -The international arrangement on the mutual recognition of certificates based on the CC -(Common Criteria Recognition Arrangement, CCRA-2014) has been ratified on 08 -September 2014. It covers CC certificates based on collaborative Protection Profiles (cPP) -(exact use), certificates based on assurance components up to and including EAL 2 or the -assurance family Flaw Remediation (ALC_FLR) and certificates for Protection Profiles and -for collaborative Protection Profiles (cPP). -The CCRA-2014 replaces the old CCRA signed in May 2000 (CCRA-2000). Certificates -based on CCRA-2000, issued before 08 September 2014 are still under recognition -according to the rules of CCRA-2000. For on 08 September 2014 ongoing certification -procedures and for Assurance Continuity (maintenance and re-certification) of old -certificates a transition period on the recognition of certificates according to the rules of -CCRA-2000 (i.e. assurance components up to and including EAL 4 or the assurance -family Flaw Remediation (ALC_FLR)) is defined until 08 September 2017. -As of September 2014 the signatories of the new CCRA are government representatives -from the following nations: Australia, Austria, Canada, Czech Republic, Denmark, Finland, -France, Germany, Greece, Hungary, India, Israel, Italy, Japan, Malaysia, The Netherlands, -New Zealand, Norway, Pakistan, Republic of Korea, Singapore, Spain, Sweden, Turkey, -United Kingdom, and the United States. -The current list of signatory nations and approved certification schemes can be seen on -the website: http://www.commoncriteriaportal.org. -The Common Criteria Recognition Arrangement logo printed on the certificate indicates -that this certification is recognised under the terms of this agreement by the nations listed -above. -As the product certified has been accepted into the certification process before 08 -September 2014, this certificate is recognized according to the rules of CCRA-2000, i.e. -for all assurance components selected. -3 Performance of Evaluation and Certification -The certification body monitors each individual evaluation to ensure a uniform procedure, a -uniform interpretation of the criteria and uniform ratings. -The product IBM Security Access Manager for Enterprise Single Sign-On, Version 8.2 has -undergone the certification procedure at BSI. -The evaluation of the product IBM Security Access Manager for Enterprise Single Sign-On, -Version 8.2 was conducted by atsec information security GmbH. The evaluation was -8 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -completed on 31 October 2014. atsec information security GmbH is an evaluation facility -(ITSEF)6 -recognised by the certification body of BSI. -For this certification procedure the sponsor and applicant is: IBM Corporation. -The product was developed by: IBM Corporation. -The certification is concluded with the comparability check and the production of this -Certification Report. This work was completed by the BSI. -4 Validity of the Certification Result -This Certification Report only applies to the version of the product as indicated. The -confirmed assurance package is only valid on the condition that -● all stipulations regarding generation, configuration and operation, as given in the -following report, are observed, -● the product is operated in the environment described, as specified in the following report -and in the Security Target. -For the meaning of the assurance levels please refer to the excerpts from the criteria at -the end of the Certification Report. -The Certificate issued confirms the assurance of the product claimed in the Security Target -at the date of certification. As attack methods evolve over time, the resistance of the -certified version of the product against new attack methods needs to be re-assessed. -Therefore, the sponsor should apply for the certified product being monitored within the -assurance continuity program of the BSI Certification Scheme (e.g. by a re-certification). -Specifically, if results of the certification are used in subsequent evaluation and certification -procedures, in a system integration process or if a user's risk management needs regularly -updated results, it is recommended to perform a re-assessment on a regular e.g. annual -basis. -In case of changes to the certified version of the product, the validity can be extended to -the new versions and releases, provided the sponsor applies for assurance continuity (i.e. -re-certification or maintenance) of the modified product, in accordance with the procedural -requirements, and the evaluation does not reveal any security deficiencies. -5 Publication -The product IBM Security Access Manager for Enterprise Single Sign-On, Version 8.2 has -been included in the BSI list of certified products, which is published regularly (see also -Internet: https://www.bsi.bund.de and [5]). Further information can be obtained from -BSI-Infoline +49 228 9582-111. -Further copies of this Certification Report can be requested from the developer7 -of the -product. The Certification Report may also be obtained in electronic form at the internet -address stated above. -6 -Information Technology Security Evaluation Facility -7 -IBM Corporation -11501 Burnet Road -Austin -Texas -9 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -This page is intentionally left blank. -10 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -B Certification Results -The following results represent a summary of -● the Security Target of the sponsor for the Target of Evaluation, -● the relevant evaluation results from the evaluation facility, and -● complementary notes and stipulations of the certification body. -11 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -1 Executive Summary -The Target of Evaluation (TOE) is IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and AccessAgent Fix Pack 22. It is an -enterprise single-sign-on product for Microsoft Windows-based systems. The TOE -automatically, driven by rules, enters user credentials into credential-requesting -applications on behalf of the user once the user has successfully authenticated to the -TOE. The TOE further provides functions to audit user actions, protect the user's data and -manage these TOE security functions. -The Security Target [6] is the basis for this certification. It is not based on a certified -Protection Profile. -The TOE Security Assurance Requirements (SAR) are based entirely on the assurance -components defined in Part 3 of the Common Criteria (see part C or [1], Part 3 for details). -The TOE meets the assurance requirements of the Evaluation Assurance Level EAL 3 -augmented by ALC_FLR.1. -The TOE Security Functional Requirements (SFR) relevant for the TOE are outlined in the -Security Target [6], chapter 6.1. They are all selected from Common Criteria Part 2. Thus -the TOE is CC Part 2 conformant. -The TOE Security Functional Requirements are implemented by the following TOE -Security Functionality: -TOE Security Functionality Addressed issue -Audit Various components of the product generate audit events -which are stored in the IMS Server database. All user -application access logs are collated into the IMS Server's -audit log database. Each log record contains info related to -time and location from which a user accesses a certain -application. -Identification and Authentication The TOE supports an identification mechanism and an -authentication mechanism. The TOE maintains its own user -repository and performs user authentication against various -forms of authentication credentials stored in this repository -(stored in the IMS Server database). The user's ISAM E-SSO -Password is created when the account is first created (when -the user first sign's up). -User Data Protection The TOE supports a user data protection mechanism. The -TOE stores each user's credential data in a Wallet; one Wallet -per-user. A Wallet provides confidentiality and integrity -protection of the user credential data through the use of -cryptographic operations. All cryptographic operations are -performed by the Operational Environment. -Security management The TOE supports security function management -mechanisms. Role-based access control is used to protect -access to operations in the AccessAdmin and AccessAssistant -applications. -Table 1: TOE Security Functionalities -For more details please refer to the Security Target [6], chapter 7.1. -12 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -The assets to be protected by the TOE are defined in the Security Target [6], chapter 3.1. -Based on these assets the TOE Security Problem is defined in terms of Assumptions, -Threats and Organisational Security Policies. This is outlined in the Security Target [6], -chapter 3.1 - 3.3. -This certification covers the configurations of the TOE as outlined in chapter 8. -The vulnerability assessment results as stated within this certificate do not include a rating -for those cryptographic algorithms and their implementation suitable for encryption and -decryption (see BSIG Section 9, Para. 4, Clause 2). -The certification results only apply to the version of the product indicated in the certificate -and on the condition that all the stipulations are kept as detailed in this Certification -Report. This certificate is not an endorsement of the IT product by the Federal Office for -Information Security (BSI) or any other organisation that recognises or gives effect to this -certificate, and no warranty of the IT product by BSI or any other organisation that -recognises or gives effect to this certificate, is either expressed or implied. -2 Identification of the TOE -The Target of Evaluation (TOE) is called: -IBM Security Access Manager for Enterprise Single Sign-On, Version 8.2 -The following table outlines the TOE deliverables: -No Type Identifier Release Form of -Delivery -1 SW IBM Security Access Manager for Enterprise -Single Sign on Suite (32bit) -8.2.0, Part Number -CRH6SML -DL -2 SW IBM Security Access Manager for Enterprise -Single Sign on Suite (64bit) -8.2.0, Part Number CRH6TML DL -3 SW IMS Server Interim Fix 04 8.2.0 -(8.2.0-ISSSAMESSOIMSIF00 -04.zip) -DL -4 SW Access Agent Fixpack 22 (32bit) 8.2.0 -(8.2.0-ISSSAMESSOAAFP00 -22_32.msp) -DL -5 SW Access Agent Fixpack 22 (64bit) 8.2.0 -(8.2.0-ISSSAMESSOAAFP00 -22_64.msp) -DL -6 DOC IBM Security Access Manager for Enterprise -Single Sign-On Common Criteria Guide -8.2.0 (SC27-4365-00) DL -7 DOC IBM Security Access Manager for Enterprise -Single Sign-on Quick Start Guide -8.2.0 (GI11-8732-03) DL -8 DOC IBM Security Access Manager for Enterprise -Single Sign-on Installation Guide -8.2.0 (GI11-9309-01) DL -9 DOC IBM Security Access Manager for Enterprise -Single Sign-on Configuration Guide -8.2.0 (GC23-9692-01) DL -10 DOC IBM Security Access Manager for Enterprise -Single Sign-on Deployment Guide -8.2.0 (SC23-9952-03) DL -11 DOC IBM Security Access Manager for Enterprise -Single Sign-On Administrator Guide -8.2.0 (SC23-9951-03) DL -13 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -No Type Identifier Release Form of -Delivery -12 DOC IBM Security Access Manager for Enterprise -Single Sign-on User Guide -8.2.0 (SC23-9950-03) DL -13 DOC IBM Security Access Manager for Enterprise -Single Sign-on Help Desk Guide -8.2.0 (SC23-9953-03) DL -14 DOC IBM Security Access Manager for Enterprise -Single Sign-on Troubleshooting and Support -Guide -8.2.0 (GC23-9693-01) DL -15 DOC IBM Security Access Manager for Enterprise -Single Sign-on AccessStudio Guide -8.2.0 (SC23-9956-03) DL -16 DOC IBM Security Access Manager for Enterprise -Single Sign-On Policies Definition Guide -8.2.0 (SC23-9694-01) DL -17 DOC IBM Security Access Manager for Enterprise -Single Sign-on Provisioning Integration Guide -8.2.0 (SC23-9957-03) DL -18 DOC IBM Security Access Manager for Enterprise -Single Sign-On Web API for Credential -Management Guide -8.2.0 (SC14-7646-00) DL -19 DOC IBM Security Access Manager for Enterprise -Single Sign-on Context Management Integration -Guide -8.2.0 (SC23-9954-03) DL -20 DOC IBM Security Access Manager for Enterprise -Single Sign-On Serial ID SPI Guide -8.2.0 (SC14-7626-00) DL -21 DOC IBM Security Access Manager for Enterprise -Single Sign-On Lightweight AccessAgent mode -on Terminal Server SDK Guide -8.2.0 (SC14-7657-00) DL -22 DOC IBM Security Access Manager for Enterprise -Single Sign-On Error Message Reference -Guide -8.2.0 (GC14-7624-00) DL -Table 2: Deliverables of the TOE -The TOE is electronically downloaded using 2 steps: -1. The base version of the TOE is to be downloaded from passport advantage. -2. The TOE Fixpacks as well as the documentation is electronically downloaded from -the IBM support site. -The downloads are to be carried using the secure Download Director protocol. -The TOE can be identified by the user by its version numbers. The Access Agent version -number is: 8.2.0.3458. The IMS Version number is: 8.2.0.696 -3 Security Policy -The Security Policy is expressed by the set of Security Functional Requirements and -implemented by the TOE. It covers the following issues: -● Access Profiles: The TOE only releases a subset of the credential information -stored in a user's Wallet to the target application the user intends to identify and -authenticate to based on Access Profiles. -14 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -● Audit: The TOE shall offer an audit mechanism that can be used to hold users of -each role accountable for security-relevant actions performed with the TSF. -● Authentication: The TOE must ensure that only authorized users gain access to -the TOE and its resources. -● Manage: The TSF must provide all the functions and facilities necessary to support -the authorized users that are responsible for the management of TOE security -mechanisms and must ensure that only authorized users are able to access such -functionality. -● Role: The TOE must assign a role to each user after successful identification and -authentication to the management facility. This role limits the management actions -the user is allowed to perform. -● Password Quality: When in GINA mode with Active Directory password -synchronization disabled, the TOE must ensure that the quality of the ISAM E-SSO -Password protecting the Common Symmetric Key (CSK) must possess the strength -to prevent credential guessing from threat agents. -● Wallet Access: The TOE must ensure that users can only access the contents of -the Wallet assigned to them. -4 Assumptions and Clarification of Scope -The Assumptions defined in the Security Target and some aspects of Threats and -Organisational Security Policies are not covered by the TOE itself. These aspects lead to -specific security objectives to be fulfilled by the TOE-Environment. The following topics are -of relevance: -● Cryptographic operations -● Competent individuals -● Password quality -● Physical protection -● Runtime environment -● Time source -● Users -Details can be found in the Security Target [6], chapter 4.2. -5 Architectural Information -The TOE consists of multiple components executing in a distributed environment and -communicating using the network. Figure 1 in the Security Target [6] depicts the different -components forming the product. Each of the green shaded components are described in -the subsequent sections in the Security Target [6], chapter 1.5.2. These green shaded -components together form the TOE. -15 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -6 Documentation -The evaluated documentation as outlined in table 2 is being provided with the product to -the customer. This documentation contains the required information for secure usage of -the TOE in accordance with the Security Target. -Additional obligations and notes for secure usage of the TOE as outlined in chapter 10 of -this report have to be followed. -7 IT Product Testing -7.1 Developer Testing -The developer used 24 manual test cases where each test case may contain up to 100 -sub tests (each test testing a specific aspect of a functionality). -Two test scripts are used that automatically test several functions related to wallet and role -management. The developer test evidence comprises many more tests cases but the -majority of them is not relevant for the evaluated functions. -7.1.1 Test Configuration -The developer tested all supported agent and IMS server platforms: -● AccessAgent on Windows XP/7 on 32bit and 64 bit (it includes GSKit which is part -of the TOE environment) -● IMS server on Windows Server 2008 32bit and 64bit -● WebSphere 7 (which includes Java) for databases, IBM DB2, Microsoft SQL Server, -and Oracle Database has been tested -Other settings relevant for the evaluated configuration (e.g. password strength or -enable/disabling certain functions) have been only used when it is needed for the tests. -7.1.2 Test approach -The manual developer tests were designed to use the GUI (Access Agent or IMS server -web interfaces). The manual tests consists of several test plan documents where one -document refers to the regression testing. The regression testing is a large collection of -tests that have been collected over time for each new version of the product. This ensures -that old functions still work on the latest release version. -The automated tests use the IMS API which is an internal TOE interface to the IMS server. -7.1.3 Testing Results -The developer testing was performed successfully with no exceptions by the developer on -all supported platforms. -7.2 Evaluator Testing Effort -The evaluator chose 28 developer tests for independent testing and created 7 new test -cases. -16 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -7.2.1 Test Approach and Depth -The evaluator witnessed parts developer tests via a web conference, where a subset (9 -developer tests) of the developer tests were executed based on the evaluator's choice. -18 other developer tests and all but one evaluator test have been executed on in the -ITSEF lab where the TOE has been installed. The evaluator test which involves the use of -the AccessStudio for access profiles application was performed on the developer test -systems. -The evaluators choice of the developer tests was to test all security functions (apart from -the auditing) and to also see all different types of supported platforms working. Specifically, -the following areas are covered by the independent testing of developer tests: -● releasing credentials to web applications and non-web applications as the core -functionality of the single-sign on operations -● authentication of AccessAgent users and IMS administrators -● policy management by help desk and administrative user roles -● password management by users -For the evaluator tests, the focus lay on: -● audit generation and review, especially testing the interaction between the -AccessAgent and the IMS server so that audit events get exchanged -● AccessAgent authentication in case the respective AD user account gets changed -(e.g. disabled) or client installation is not part of the AD domain -● creation and application of access profiles (the access profile that was created as -part of this test was used as input to the penetration testing when attempting to -obtain user credentials by forging applications) -All subsystems have been tested: while the tests of the user authentication applied to the -AccessAgent, all management and admin authentication tests used the AccessAdmin and -AccessAssistant subsystems. The IMS runtime was tested indirectly by using the -AccessAgent because the agent uses the IMS server interface to communicate with the -server. The configuration utilities were tested too as part of the access profile upload and -TOE configuration steps. -7.2.2 Test Configuration -The evaluator test configuration was the following: -● two AccessAgent (FixPack 22) client machines with WinXP 32-bit as underlying -platform -● IMS (Interim Fix 4) server installation with Windows Server 2008 32-bit as -underlying platform -● Active Directory as User Registry -● Applied configuration according to the evaluate configuration in the guidance as -necessary for the testing -● IBM DB2 9.7 -The developer test setup consisted of a broader number of platforms (covering all -platforms that are defined for the evaluated configuration): -17 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -● AccessAgent: WinXP 32/64 bit, Windows 7 32/64 bit -● IMS Server: Windows Server 2008 32/64 bit -7.2.3 Test Results -All tests have been performed successfully with the actual results matching the expected -results. -7.3 Evaluator Penetration Testing -The evaluator used the CVE for finding publicly documented vulnerabilities. None of the -found entries required independent testing. -The test effort based on all the developer evidence lead to the test of 14 potential -vulnerabilities, where some vulnerabilities might apply to a number of different functions. -Therefore, several tests where subdivided into testing the vulnerability aspect on several -functions. -The test approach was to generally aiming at authentication and authorization functions of -the TOE, i.e., the IMS server that enforces these security functions. This has been -performed through attempting to gain access to TOE interfaces that should not be -externally accessible, or use functions with unexpected parameter values (e.g. the -AccessAgent uses the IMS server login functions by always providing the correct domain -identifier, which is not the case when crafting requests to the IMS server manually). -Considering the type of the security functions that were attempted to violate, the testing -can be divided into these effects: -Testing the usability of invisible/deprecated functions that may violate authentication TSF, -as well as standard authentication functions with ill-formed parameters. -Testing the usability of invisible/deprecated functions that may violate authorization TSF, -as well as standard authorization functions. -Implicit test of wallet integrity through manipulating wallet data and its effect on single sign -for application. A brute-force attack was tested to verify whether the SFR for verification of -secrets holds. -Other tests were not target against a specific security objective, but attempted to observe -any suspicious behavior as a result of the ill-formed input data tests, which could then be -further analyzed. -Another group of tests where used to spot any interface functions among the complex -SOAP and WebSphere provided interfaces, that are available despite being hidden from -the network view according to the FSP. Any unexpectedly available interface could be -used to violate management function requirements. -7.3.1 Test configuration -The tests were performed on the TOE that was installed on one of the supported -WebSphere Application Server 7.0 on a Microsoft Windows Server 2008 32-bit platform for -the IMS server and a Microsoft Windows XP client installation. The test configuration in -terms of the evaluated configuration settings and software versions was the same than for -the evaluator's independent testing (following the evaluated configuration defined in the -CC-specific guidance provided by the developer). -18 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -7.3.2 Results -The tests showed that a few more functions allow a password authentication but none of -the penetration tests revealed an exploitable vulnerability. -8 Evaluated Configuration -This certification covers the following configuration of the TOE: -● The use of personal secrets must be disabled. -● Only the AccessAgent plugins provided with the TOE are allowed. -● Only the ISAM E-SSO Password authentication factor is allowed. -● Second factor authentication is disallowed. -● Self-service policies: -● Self-service password reset must be disabled. -● Self-service authorization code issuance must be disabled. -● Self-service registration and bypass of 2nd factor must be disabled. -● Self-service registering of additional secrets during sign-up must be disabled. -● The IMS Server's master secret must be protected to only allow the Administrator -role access to it. -● One-Time Passwords (OTPs) must be disabled. -● Mobile ActiveCode (MAC) must be disabled. -● Roaming Desktops (i.e., the use of Microsoft Windows Terminal Server and Citrix -Presentation Server) must be disabled. -● RADIUS authentication must be disabled. -● Windows Fast User Switching must be disabled on Windows 7 systems running -AccessAgent. -● Private Desktop must be disabled on Windows XP systems running AccessAgent. -● Single sign-on to AccessAdmin when using Microsoft Internet Explorer must be -disabled. -● The IMS Server/application must be the only application running in the WebSphere -Application Server (WAS). -● The TOE's password synchronization option with Active Directory affects the -security of the TOE. Specifically, enabling password synchronization with Active -Directory will disable the TOE's ability to enforce password quality requirements. -● The feedback email settings in AccessAssistant and Web Workplace must not be -enabled. -19 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -9 Results of the Evaluation -9.1 CC specific results -The Evaluation Technical Report (ETR) [7] was provided by the ITSEF according to the -Common Criteria [1], the Methodology [2], the requirements of the Scheme [3] and all -interpretations and guidelines of the Scheme (AIS) [4] as relevant for the TOE. -The Evaluation Methodology CEM [2] was used. -As a result of the evaluation the verdict PASS is confirmed for the following assurance -components: -● All components of the EAL 3 package including the class ASE as defined in the CC (see -also part C of this report) -● The components ALC_FLR.1 augmented for this TOE evaluation. -The evaluation has confirmed: -● for the Functionality: Product specific Security Target -Common Criteria Part 2 conformant -● for the Assurance: Common Criteria Part 3 conformant -EAL 3 augmented by ALC_FLR.1 -The results of the evaluation are only applicable to the TOE as defined in chapter 2 and -the configuration as outlined in chapter 8 above. -9.2 Results of cryptographic assessment -The TOE does not include cryptographic mechanisms. Thus, no such mechanisms were -part of the assessment. -10 Obligations and Notes for the Usage of the TOE -The documents as outlined in table 2 contain necessary information about the usage of the -TOE and all security hints therein have to be considered. In addition all aspects of -Assumptions, Threats and OSPs as outlined in the Security Target not covered by the TOE -itself need to be fulfilled by the operational environment of the TOE. -The customer or user of the product shall consider the results of the certification within his -system risk management process. In order for the evolution of attack methods and -techniques to be covered, he should define the period of time until a re-assessment of the -TOE is required and thus requested from the sponsor of the certificate. -If available, certified updates of the TOE should be used. If non-certified updates or -patches are available the user of the TOE should request the sponsor to provide a -re-certification. In the meantime a risk management process of the system using the TOE -should investigate and decide on the usage of not yet certified updates and patches or -take additional measures in order to maintain system security. -11 Security Target -For the purpose of publishing, the Security Target [6] of the Target of Evaluation (TOE) is -provided within a separate document as Annex A of this report. -20 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -12 Definitions -12.1 Acronyms -AIS Application Notes and Interpretations of the Scheme -BSI Bundesamt für Sicherheit in der Informationstechnik / Federal Office for -Information Security, Bonn, Germany -BSIG BSI-Gesetz / Act on the Federal Office for Information Security -CCRA Common Criteria Recognition Arrangement -CC Common Criteria for IT Security Evaluation -CEM Common Methodology for Information Technology Security Evaluation -cPP Collaborative Protection Profile -EAL Evaluation Assurance Level -ETR Evaluation Technical Report -IT Information Technology -ITSEF Information Technology Security Evaluation Facility -PP Protection Profile -SAR Security Assurance Requirement -SFP Security Function Policy -SFR Security Functional Requirement -ST Security Target -TOE Target of Evaluation -TSF TOE Security Functionality -12.2 Glossary -Augmentation - The addition of one or more requirement(s) to a package. -Collaborative Protection Profile - A Protection Profile collaboratively developed by an -International Technical Community endorsed by the Management Committee. -Extension - The addition to an ST or PP of functional requirements not contained in CC -part 2 and/or assurance requirements not contained in CC part 3. -Formal - Expressed in a restricted syntax language with defined semantics based on -well-established mathematical concepts. -Informal - Expressed in natural language. -Object - A passive entity in the TOE, that contains or receives information, and upon which -subjects perform operations. -Package - named set of either security functional or security assurance requirements -Protection Profile - A formal document defined in CC, expressing an implementation -independent set of security requirements for a category of IT Products that meet specific -consumer needs. -21 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -Security Target - An implementation-dependent statement of security needs for a specific -identified TOE. -Semiformal - Expressed in a restricted syntax language with defined semantics. -Subject - An active entity in the TOE that performs operations on objects. -Target of Evaluation - An IT Product and its associated administrator and user guidance -documentation that is the subject of an Evaluation. -TOE Security Functionality - Combined functionality of all hardware, software, and -firmware of a TOE that must be relied upon for the correct enforcement of the SFRs. -22 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -13 Bibliography -[1] Common Criteria for Information Technology Security Evaluation, Version 3.1, -Part 1: Introduction and general model, Revision 3, July 2009 -Part 2: Security functional components, Revision 3, July 2009 -Part 3: Security assurance components, Revision 3, July 2009 -[2] Common Methodology for Information Technology Security Evaluation (CEM), -Evaluation Methodology, Version 3.1, Rev. 3, July 2009 -[3] BSI certification: Technical information on the IT security certification of products, -protection profiles and sites (BSI 7138) and Requirements regarding the Evaluation -Facility for the Evaluation of Products, Protection Profiles and Sites under the CC -and ITSEC (BSI 7125) -[4] Application Notes and Interpretations of the Scheme (AIS) as relevant for the TOE8 -. -[5] German IT Security Certificates (BSI 7148), periodically updated list published also -in the BSI Website -[6] Security Target BSI-DSZ-CC-0683-2014, Version 1.19, 2014-03-05, IBM Security -Access Manager for Enterprise Single Sign-On Version 8.2 with IMS Server Interim -Fix 4 and AccessAgent Fix Pack 22 Security Target, IBM Corporation -[7] Evaluation Technical Report, Version 2, 2014-09-22, Final Evaluation Technical -Report, atsec information security GmbH, (confidential document) -[8] CM Lists, file name: CM.LISTS.real-final-final-final.zip, Date: 2014-09-22 -[9] Security Access Manager for Enterprise Single Sign-On: Configuration Guide, -Version GC23-9692-01, Date: 2012-04-02 -8 -specifically -• AIS 1, Version 13, Durchführung der Ortsbesichtigung in der Entwicklungsumgebung des -Herstellers -• AIS 23, Version 3, Zusammentragen von Nachweisen der Entwickler (Collection of Developer -Evidence) -• AIS 32, Version 7, CC-Interpretationen im deutschen Zertifizierungsschema -23 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -This page is intentionally left blank. -24 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -C Excerpts from the Criteria -CC Part 1: -Conformance Claim (chapter 10.4) -“The conformance claim indicates the source of the collection of requirements that is met -by a PP or ST that passes its evaluation. This conformance claim contains a CC -conformance claim that: -● describes the version of the CC to which the PP or ST claims conformance. -● describes the conformance to CC Part 2 (security functional requirements) as either: -– CC Part 2 conformant - A PP or ST is CC Part 2 conformant if all SFRs in that -PP or ST are based only upon functional components in CC Part 2, or -– CC Part 2 extended - A PP or ST is CC Part 2 extended if at least one SFR in -that PP or ST is not based upon functional components in CC Part 2. -● describes the conformance to CC Part 3 (security assurance requirements) as either: -– CC Part 3 conformant - A PP or ST is CC Part 3 conformant if all SARs in that -PP or ST are based only upon assurance components in CC Part 3, or -– CC Part 3 extended - A PP or ST is CC Part 3 extended if at least one SAR in -that PP or ST is not based upon assurance components in CC Part 3. -Additionally, the conformance claim may include a statement made with respect to -packages, in which case it consists of one of the following: -● Package name Conformant - A PP or ST is conformant to a pre-defined package -(e.g. EAL) if: -– the SFRs of that PP or ST are identical to the SFRs in the package, or -– the SARs of that PP or ST are identical to the SARs in the package. -● Package name Augmented - A PP or ST is an augmentation of a predefined package -if: -– the SFRs of that PP or ST contain all SFRs in the package, but have at least -one additional SFR or one SFR that is hierarchically higher than an SFR in the -package. -– the SARs of that PP or ST contain all SARs in the package, but have at least -one additional SAR or one SAR that is hierarchically higher than an SAR in the -package. -Note that when a TOE is successfully evaluated to a given ST, any conformance claims of -the ST also hold for the TOE. A TOE can therefore also be e.g. CC Part 2 conformant. -Finally, the conformance claim may also include two statements with respect to Protection -Profiles: -● PP Conformant - A PP or TOE meets specific PP(s), which are listed as part of the -conformance result. -● Conformance Statement (Only for PPs) - This statement describes the manner in -which PPs or STs must conform to this PP: strict or demonstrable. For more -information on this Conformance Statement, see Annex D.” -25 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -CC Part 3: -Class APE: Protection Profile evaluation (chapter 10) -“Evaluating a PP is required to demonstrate that the PP is sound and internally consistent, -and, if the PP is based on one or more other PPs or on packages, that the PP is a correct -instantiation of these PPs and packages. These properties are necessary for the PP to be -suitable for use as the basis for writing an ST or another PP. -Assurance Class Assurance Components -Class APE: Protection -Profile evaluation -APE_INT.1 PP introduction -APE_CCL.1 Conformance claims -APE_SPD.1 Security problem definition -APE_OBJ.1 Security objectives for the operational environment -APE_OBJ.2 Security objectives -APE_ECD.1 Extended components definition -APE_REQ.1 Stated security requirements -APE_REQ.2 Derived security requirements -APE: Protection Profile evaluation class decomposition” -Class ASE: Security Target evaluation (chapter 11) -“Evaluating an ST is required to demonstrate that the ST is sound and internally -consistent, and, if the ST is based on one or more PPs or packages, that the ST is a -correct instantiation of these PPs and packages. These properties are necessary for the -ST to be suitable for use as the basis for a TOE evaluation.” -Assurance Class Assurance Components -Class ASE: Security -Target evaluation -ASE_INT.1 ST introduction -ASE_CCL.1 Conformance claims -ASE_SPD.1 Security problem definition -ASE_OBJ.1 Security objectives for the operational environment -ASE_OBJ.2 Security objectives -ASE_ECD.1 Extended components definition -ASE_REQ.1 Stated security requirements -ASE_REQ.2 Derived security requirements -ASE_TSS.1 TOE summary specification -ASE_TSS.2 TOE summary specification with architectural design -summary -ASE: Security Target evaluation class decomposition -26 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -Security assurance components (chapter 7) -“The following Sections describe the constructs used in representing the assurance -classes, families, and components.“ -“Each assurance class contains at least one assurance family.” -“Each assurance family contains one or more assurance components.” -The following table shows the assurance class decomposition. -Assurance Class Assurance Components -ADV: Development ADV_ARC.1 Security architecture description -ADV_FSP.1 Basic functional specification -ADV_FSP.2 Security-enforcing functional specification -ADV_FSP.3 Functional specification with complete summary -ADV_FSP.4 Complete functional specification -ADV_FSP.5 Complete semi-formal functional specification with -additional error information -ADV_FSP.6 Complete semi-formal functional specification with -additional formal specification -ADV_IMP.1 Implementation representation of the TSF -ADV_IMP.2 Implementation of the TSF -ADV_INT.1 Well-structured subset of TSF internals -ADV_INT.2 Well-structured internals -ADV_INT.3 Minimally complex internals -ADV_SPM.1 Formal TOE security policy model -ADV_TDS.1 Basic design -ADV_TDS.2 Architectural design -ADV_TDS.3 Basic modular design -ADV_TDS.4 Semiformal modular design -ADV_TDS.5 Complete semiformal modular design -ADV_TDS.6 Complete semiformal modular design with formal -high-level design presentation -AGD: -Guidance documents -AGD_OPE.1 Operational user guidance -AGD_PRE.1 Preparative procedures -ALC: Life cycle support -ALC_CMC.1 Labelling of the TOE -ALC_CMC.2 Use of a CM system -ALC_CMC.3 Authorisation controls -ALC_CMC.4 Production support, acceptance procedures and -automation -ALC_CMC.5 Advanced support -ALC_CMS.1 TOE CM coverage -ALC_CMS.2 Parts of the TOE CM coverage -ALC_CMS.3 Implementation representation CM coverage -ALC_CMS.4 Problem tracking CM coverage -ALC_CMS.5 Development tools CM coverage -ALC_DEL.1 Delivery procedures -ALC_DVS.1 Identification of security measures -ALC_DVS.2 Sufficiency of security measures -ALC_FLR.1 Basic flaw remediation -ALC_FLR.2 Flaw reporting procedures -ALC_FLR.3 Systematic flaw remediation -ALC_LCD.1 Developer defined life-cycle model -27 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -Assurance Class Assurance Components -ALC_LCD.2 Measurable life-cycle model -ALC_TAT.1 Well-defined development tools -ALC_TAT.2 Compliance with implementation standards -ALC_TAT.3 Compliance with implementation standards - all parts -ATE: Tests -ATE_COV.1 Evidence of coverage -ATE_COV.2 Analysis of coverage -ATE_COV.3 Rigorous analysis of coverage -ATE_DPT.1 Testing: basic design -ATE_DPT.2 Testing: security enforcing modules -ATE_DPT.3 Testing: modular design -ATE_DPT.4 Testing: implementation representation -ATE_FUN.1 Functional testing -ATE_FUN.2 Ordered functional testing -ATE_IND.1 Independent testing – conformance -ATE_IND.2 Independent testing – sample -ATE_IND.3 Independent testing – complete -AVA: Vulnerability -assessment -AVA_VAN.1 Vulnerability survey -AVA_VAN.2 Vulnerability analysis -AVA_VAN.3 Focused vulnerability analysis -AVA_VAN.4 Methodical vulnerability analysis -AVA_VAN.5 Advanced methodical vulnerability analysis -Assurance class decomposition -Evaluation assurance levels (chapter 8) -“The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the -level of assurance obtained with the cost and feasibility of acquiring that degree of -assurance. The CC approach identifies the separate concepts of assurance in a TOE at -the end of the evaluation, and of maintenance of that assurance during the operational use -of the TOE. -It is important to note that not all families and components from CC Part 3 are included in -the EALs. This is not to say that these do not provide meaningful and desirable -assurances. Instead, it is expected that these families and components will be considered -for augmentation of an EAL in those PPs and STs for which they provide utility.” -Evaluation assurance level (EAL) overview (chapter 8.1) -“Table 1 represents a summary of the EALs. The columns represent a hierarchically -ordered set of EALs, while the rows represent assurance families. Each number in the -resulting matrix identifies a specific assurance component where applicable. -As outlined in the next Section, seven hierarchically ordered evaluation assurance levels -are defined in the CC for the rating of a TOE's assurance. They are hierarchically ordered -inasmuch as each EAL represents more assurance than all lower EALs. The increase in -assurance from EAL to EAL is accomplished by substitution of a hierarchically higher -assurance component from the same assurance family (i.e. increasing rigour, scope, -and/or depth) and from the addition of assurance components from other assurance -families (i.e. adding new requirements). -These EALs consist of an appropriate combination of assurance components as described -in Chapter 7 of this CC Part 3. More precisely, each EAL includes no more than one -28 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -component of each assurance family and all assurance dependencies of every component -are addressed. -While the EALs are defined in the CC, it is possible to represent other combinations of -assurance. Specifically, the notion of “augmentation” allows the addition of assurance -components (from assurance families not already included in the EAL) or the substitution -of assurance components (with another hierarchically higher assurance component in the -same assurance family) to an EAL. Of the assurance constructs defined in the CC, only -EALs may be augmented. The notion of an “EAL minus a constituent assurance -component” is not recognised by the standard as a valid claim. Augmentation carries with -it the obligation on the part of the claimant to justify the utility and added value of the -added assurance component to the EAL. An EAL may also be augmented with extended -assurance requirements. -Evaluation assurance level 1 (EAL 1) - functionally tested (chapter 8.3) -“Objectives -EAL 1 is applicable where some confidence in correct operation is required, but the threats -to security are not viewed as serious. It will be of value where independent assurance is -required to support the contention that due care has been exercised with respect to the -protection of personal or similar information. -EAL 1 requires only a limited security target. It is sufficient to simply state the SFRs that -the TOE must meet, rather than deriving them from threats, OSPs and assumptions -through security objectives. -EAL 1 provides an evaluation of the TOE as made available to the customer, including -independent testing against a specification, and an examination of the guidance -documentation provided. It is intended that an EAL 1 evaluation could be successfully -conducted without assistance from the developer of the TOE, and for minimal outlay. -An evaluation at this level should provide evidence that the TOE functions in a manner -consistent with its documentation.” -Evaluation assurance level 2 (EAL 2) - structurally tested (chapter 8.4) -“Objectives -EAL 2 requires the co-operation of the developer in terms of the delivery of design -information and test results, but should not demand more effort on the part of the -developer than is consistent with good commercial practise. As such it should not require a -substantially increased investment of cost or time. -EAL 2 is therefore applicable in those circumstances where developers or users require a -low to moderate level of independently assured security in the absence of ready -availability of the complete development record. Such a situation may arise when securing -legacy systems, or where access to the developer may be limited.” -Evaluation assurance level 3 (EAL 3) - methodically tested and checked (chapter 8.5) -“Objectives -EAL 3 permits a conscientious developer to gain maximum assurance from positive -security engineering at the design stage without substantial alteration of existing sound -development practises. -29 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -EAL 3 is applicable in those circumstances where developers or users require a moderate -level of independently assured security, and require a thorough investigation of the TOE -and its development without substantial re-engineering.” -Evaluation assurance level 4 (EAL 4) - methodically designed, tested, and reviewed -(chapter 8.6) -“Objectives -EAL 4 permits a developer to gain maximum assurance from positive security engineering -based on good commercial development practises which, though rigorous, do not require -substantial specialist knowledge, skills, and other resources. EAL 4 is the highest level at -which it is likely to be economically feasible to retrofit to an existing product line. -EAL 4 is therefore applicable in those circumstances where developers or users require a -moderate to high level of independently assured security in conventional commodity TOEs -and are prepared to incur additional security-specific engineering costs.” -Evaluation assurance level 5 (EAL 5) - semiformally designed and tested (chapter -8.7) -“Objectives -EAL 5 permits a developer to gain maximum assurance from security engineering based -upon rigorous commercial development practises supported by moderate application of -specialist security engineering techniques. Such a TOE will probably be designed and -developed with the intent of achieving EAL 5 assurance. It is likely that the additional costs -attributable to the EAL 5 requirements, relative to rigorous development without the -application of specialised techniques, will not be large. -EAL 5 is therefore applicable in those circumstances where developers or users require a -high level of independently assured security in a planned development and require a -rigorous development approach without incurring unreasonable costs attributable to -specialist security engineering techniques.” -Evaluation assurance level 6 (EAL 6) - semiformally verified design and tested -(chapter 8.8) -“Objectives -EAL 6 permits developers to gain high assurance from application of security engineering -techniques to a rigorous development environment in order to produce a premium TOE for -protecting high value assets against significant risks. -EAL 6 is therefore applicable to the development of security TOEs for application in high -risk situations where the value of the protected assets justifies the additional costs.” -Evaluation assurance level 7 (EAL 7) - formally verified design and tested -(chapter 8.9) -“Objectives -EAL 7 is applicable to the development of security TOEs for application in extremely high -risk situations and/or where the high value of the assets justifies the higher costs. Practical -application of EAL 7 is currently limited to TOEs with tightly focused security functionality -that is amenable to extensive formal analysis.” -30 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -Assurance -Class -Assurance -Family -Assurance Components by -Evaluation Assurance Level -EAL 1 EAL 2 EAL 3 EAL 4 EAL 5 EAL 6 EAL 7 -Development ADV_ARC 1 1 1 1 1 1 -ADV_FSP 1 2 3 4 5 5 6 -ADV_IMP 1 1 2 2 -ADV_INT 2 3 3 -ADV_SPM 1 1 -ADV_TDS 1 2 3 4 5 6 -Guidance -Documents -AGD_OPE 1 1 1 1 1 1 1 -AGD_PRE 1 1 1 1 1 1 1 -Life cycle -Support -ALC_CMC 1 2 3 4 4 5 5 -ALC_CMS 1 2 3 4 5 5 5 -ALC_DEL 1 1 1 1 1 1 -ALC_DVS 1 1 1 2 2 -ALC_FLR -ALC_LCD 1 1 1 1 2 -ALC_TAT 1 2 3 3 -Security Target -Evaluation -ASE_CCL 1 1 1 1 1 1 1 -ASE_ECD 1 1 1 1 1 1 1 -ASE_INT 1 1 1 1 1 1 1 -ASE_OBJ 1 2 2 2 2 2 2 -ASR_REQ 1 2 2 2 2 2 2 -ASE_SPD 1 1 1 1 1 1 -ASE_TSS 1 1 1 1 1 1 1 -Tests ATE_COV 1 2 2 2 3 3 -ATE_DPT 1 1 3 3 4 -ATE_FUN 1 1 1 1 2 2 -ATE_IND 1 2 2 2 2 2 3 -Vulnerability -assessment -AVA_VAN 1 2 2 3 4 5 5 -Table 1: Evaluation assurance level summary” -31 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -Class AVA: Vulnerability assessment (chapter 16) -“The AVA: Vulnerability assessment class addresses the possibility of exploitable -vulnerabilities introduced in the development or the operation of the TOE.” -Vulnerability analysis (AVA_VAN) (chapter 16.1) -“Objectives -Vulnerability analysis is an assessment to determine whether potential vulnerabilities -identified, during the evaluation of the development and anticipated operation of the TOE -or by other methods (e.g. by flaw hypotheses or quantitative or statistical analysis of the -security behaviour of the underlying security mechanisms), could allow attackers to violate -the SFRs. -Vulnerability analysis deals with the threats that an attacker will be able to discover flaws -that will allow unauthorised access to data and functionality, allow the ability to interfere -with or alter the TSF, or interfere with the authorised capabilities of other users.” -32 / 34 - BSI-DSZ-CC-0683-2014 Certification Report -D Annexes -List of annexes of this certification report -Annex A: Security Target provided within a separate document. -33 / 34 - Certification Report BSI-DSZ-CC-0683-2014 -This page is intentionally left blank. -34 / 34 - \ No newline at end of file diff --git a/tests/data/cc/analysis/certs/reports/txt/ed91ff3e658457fd.txt b/tests/data/cc/analysis/certs/reports/txt/ed91ff3e658457fd.txt new file mode 100644 index 00000000..ed1ca246 --- /dev/null +++ b/tests/data/cc/analysis/certs/reports/txt/ed91ff3e658457fd.txt @@ -0,0 +1,1068 @@ +BSI-DSZ-CC-0683-2014 +for +IBM Security Access Manager for Enterprise +Single Sign-On, Version 8.2 +from +IBM Corporation + BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn +Phone +49 (0)228 99 9582-0, Fax +49 (0)228 9582-5477, Infoline +49 (0)228 99 9582-111 +Certification Report V1.0 CC-Zert-327 V5.02 + BSI-DSZ-CC-0683-2014 +Access Control System +IBM Security Access Manager for Enterprise Single Sign-On +Version 8.2 +from: IBM Corporation +PP Conformance: None +Functionality: Product specific Security Target +Common Criteria Part 2 conformant +Assurance: Common Criteria Part 3 conformant +EAL 3 augmented by ALC_FLR.1 +SOGIS +Recognition Agreement +The IT Product identified in this certificate has been evaluated at an approved evaluation +facility using the Common Methodology for IT Security Evaluation (CEM), Version 3.1 for +conformance to the Common Criteria for IT Security Evaluation (CC), Version 3.1. CC and +CEM are also published as ISO/IEC 15408 and ISO/IEC 18045. +This certificate applies only to the specific version and release of the product in its +evaluated configuration and in conjunction with the complete Certification Report. +The evaluation has been conducted in accordance with the provisions of the certification +scheme of the German Federal Office for Information Security (BSI) and the conclusions +of the evaluation facility in the evaluation technical report are consistent with the evidence +adduced. +This certificate is not an endorsement of the IT Product by the Federal Office for +Information Security or any other organisation that recognises or gives effect to this +certificate, and no warranty of the IT Product by the Federal Office for Information +Security or any other organisation that recognises or gives effect to this certificate, is +either expressed or implied. +Common Criteria +Recognition Arrangement +Bonn, 5 December 2014 +For the Federal Office for Information Security +Bernd Kowalski L.S. +Head of Department +Bundesamt für Sicherheit in der Informationstechnik +Godesberger Allee 185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn +Phone +49 (0)228 99 9582-0 - Fax +49 (0)228 9582-5477 - Infoline +49 (0)228 99 9582-111 + Certification Report BSI-DSZ-CC-0683-2014 +This page is intentionally left blank. +6 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +Preliminary Remarks +Under the BSIG1 +Act, the Federal Office for Information Security (BSI) has the task of +issuing certificates for information technology products. +Certification of a product is carried out on the instigation of the vendor or a distributor, +hereinafter called the sponsor. +A part of the procedure is the technical examination (evaluation) of the product according +to the security criteria published by the BSI or generally recognised security criteria. +The evaluation is normally carried out by an evaluation facility recognised by the BSI or by +BSI itself. +The result of the certification procedure is the present Certification Report. This report +contains among others the certificate (summarised assessment) and the detailed +Certification Results. +The Certification Results contain the technical description of the security functionality of +the certified product, the details of the evaluation (strength and weaknesses) and +instructions for the user. +1 +Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August 2009, +Bundesgesetzblatt I p. 2821 +5 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +Contents +A Certification.........................................................................................................................7 +1 Specifications of the Certification Procedure..................................................................7 +2 Recognition Agreements.................................................................................................7 +3 Performance of Evaluation and Certification...................................................................8 +4 Validity of the Certification Result....................................................................................9 +5 Publication.......................................................................................................................9 +B Certification Results..........................................................................................................11 +1 Executive Summary......................................................................................................12 +2 Identification of the TOE................................................................................................13 +3 Security Policy...............................................................................................................14 +4 Assumptions and Clarification of Scope........................................................................15 +5 Architectural Information................................................................................................15 +6 Documentation..............................................................................................................16 +7 IT Product Testing..........................................................................................................16 +8 Evaluated Configuration................................................................................................19 +9 Results of the Evaluation...............................................................................................20 +10 Obligations and Notes for the Usage of the TOE........................................................20 +11 Security Target.............................................................................................................20 +12 Definitions....................................................................................................................21 +13 Bibliography.................................................................................................................23 +C Excerpts from the Criteria.................................................................................................25 +CC Part 1:........................................................................................................................25 +CC Part 3:........................................................................................................................26 +D Annexes............................................................................................................................33 +6 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +A Certification +1 Specifications of the Certification Procedure +The certification body conducts the procedure according to the criteria laid down in the +following: +● Act on the Federal Office for Information Security2 +● BSI Certification Ordinance3 +● BSI Schedule of Costs4 +● Special decrees issued by the Bundesministerium des Innern (Federal Ministry of the +Interior) +● DIN EN ISO/IEC 17065 standard +● BSI certification: Technical information on the IT security certification, Procedural +Description (BSI 7138) [3] +● BSI certification: Requirements regarding the Evaluation Facility (BSI 7125) [3] +● Common Criteria for IT Security Evaluation (CC), Version 3.15 +[1] also published as +ISO/IEC 15408. +● Common Methodology for IT Security Evaluation (CEM), Version 3.1 [2] also published +as ISO/IEC 18045. +● BSI certification: Application Notes and Interpretation of the Scheme (AIS) [4] +2 Recognition Agreements +In order to avoid multiple certification of the same product in different countries a mutual +recognition of IT security certificates - as far as such certificates are based on ITSEC or +CC - under certain conditions was agreed. +2.1 European Recognition of ITSEC/CC – Certificates (SOGIS-MRA) +The SOGIS-Mutual Recognition Agreement (SOGIS-MRA) Version 3 became effective in +April 2010. It defines the recognition of certificates for IT-Products at a basic recognition +level and in addition at higher recognition levels for IT-Products related to certain technical +domains only. +The basic recognition level includes Common Criteria (CC) Evaluation Assurance Levels +EAL 1 to EAL 4 and ITSEC Evaluation Assurance Levels E1 to E3 (basic). For higher +recognition levels the technical domain Smart card and similar Devices has been defined. +2 +Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August 2009, +Bundesgesetzblatt I p. 2821 +3 +Ordinance on the Procedure for Issuance of a Certificate by the Federal Office for Information Security +(BSI-Zertifizierungsverordnung, BSIZertV) of 07 July 1992, Bundesgesetzblatt I p. 1230 +4 +Schedule of Cost for Official Procedures of the Bundesamt für Sicherheit in der Informationstechnik +(BSI-Kostenverordnung, BSI-KostV) of 03 March 2005, Bundesgesetzblatt I p. 519 +5 +Proclamation of the Bundesministerium des Innern of 12 February 2007 in the Bundesanzeiger dated +23 February 2007, p. 3730 +7 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +It includes assurance levels beyond EAL 4 resp. E3 (basic). In addition, certificates issued +for Protection Profiles based on Common Criteria are part of the recognition agreement. +As of September 2011 the new agreement has been signed by the national bodies of +Austria, Finland, France, Germany, Italy, The Netherlands, Norway, Spain, Sweden and +the United Kingdom. Details on recognition and the history of the agreement can be found +at https://www.bsi.bund.de/zertifizierung. +The SOGIS-MRA logo printed on the certificate indicates that it is recognised under the +terms of this agreement by the nations listed above. +This certificate is recognized under SOGIS-MRA for all assurance components selected. +2.2 International Recognition of CC – Certificates (CCRA) +The international arrangement on the mutual recognition of certificates based on the CC +(Common Criteria Recognition Arrangement, CCRA-2014) has been ratified on 08 +September 2014. It covers CC certificates based on collaborative Protection Profiles (cPP) +(exact use), certificates based on assurance components up to and including EAL 2 or the +assurance family Flaw Remediation (ALC_FLR) and certificates for Protection Profiles and +for collaborative Protection Profiles (cPP). +The CCRA-2014 replaces the old CCRA signed in May 2000 (CCRA-2000). Certificates +based on CCRA-2000, issued before 08 September 2014 are still under recognition +according to the rules of CCRA-2000. For on 08 September 2014 ongoing certification +procedures and for Assurance Continuity (maintenance and re-certification) of old +certificates a transition period on the recognition of certificates according to the rules of +CCRA-2000 (i.e. assurance components up to and including EAL 4 or the assurance +family Flaw Remediation (ALC_FLR)) is defined until 08 September 2017. +As of September 2014 the signatories of the new CCRA are government representatives +from the following nations: Australia, Austria, Canada, Czech Republic, Denmark, Finland, +France, Germany, Greece, Hungary, India, Israel, Italy, Japan, Malaysia, The Netherlands, +New Zealand, Norway, Pakistan, Republic of Korea, Singapore, Spain, Sweden, Turkey, +United Kingdom, and the United States. +The current list of signatory nations and approved certification schemes can be seen on +the website: http://www.commoncriteriaportal.org. +The Common Criteria Recognition Arrangement logo printed on the certificate indicates +that this certification is recognised under the terms of this agreement by the nations listed +above. +As the product certified has been accepted into the certification process before 08 +September 2014, this certificate is recognized according to the rules of CCRA-2000, i.e. +for all assurance components selected. +3 Performance of Evaluation and Certification +The certification body monitors each individual evaluation to ensure a uniform procedure, a +uniform interpretation of the criteria and uniform ratings. +The product IBM Security Access Manager for Enterprise Single Sign-On, Version 8.2 has +undergone the certification procedure at BSI. +The evaluation of the product IBM Security Access Manager for Enterprise Single Sign-On, +Version 8.2 was conducted by atsec information security GmbH. The evaluation was +8 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +completed on 31 October 2014. atsec information security GmbH is an evaluation facility +(ITSEF)6 +recognised by the certification body of BSI. +For this certification procedure the sponsor and applicant is: IBM Corporation. +The product was developed by: IBM Corporation. +The certification is concluded with the comparability check and the production of this +Certification Report. This work was completed by the BSI. +4 Validity of the Certification Result +This Certification Report only applies to the version of the product as indicated. The +confirmed assurance package is only valid on the condition that +● all stipulations regarding generation, configuration and operation, as given in the +following report, are observed, +● the product is operated in the environment described, as specified in the following report +and in the Security Target. +For the meaning of the assurance levels please refer to the excerpts from the criteria at +the end of the Certification Report. +The Certificate issued confirms the assurance of the product claimed in the Security Target +at the date of certification. As attack methods evolve over time, the resistance of the +certified version of the product against new attack methods needs to be re-assessed. +Therefore, the sponsor should apply for the certified product being monitored within the +assurance continuity program of the BSI Certification Scheme (e.g. by a re-certification). +Specifically, if results of the certification are used in subsequent evaluation and certification +procedures, in a system integration process or if a user's risk management needs regularly +updated results, it is recommended to perform a re-assessment on a regular e.g. annual +basis. +In case of changes to the certified version of the product, the validity can be extended to +the new versions and releases, provided the sponsor applies for assurance continuity (i.e. +re-certification or maintenance) of the modified product, in accordance with the procedural +requirements, and the evaluation does not reveal any security deficiencies. +5 Publication +The product IBM Security Access Manager for Enterprise Single Sign-On, Version 8.2 has +been included in the BSI list of certified products, which is published regularly (see also +Internet: https://www.bsi.bund.de and [5]). Further information can be obtained from +BSI-Infoline +49 228 9582-111. +Further copies of this Certification Report can be requested from the developer7 +of the +product. The Certification Report may also be obtained in electronic form at the internet +address stated above. +6 +Information Technology Security Evaluation Facility +7 +IBM Corporation +11501 Burnet Road +Austin +Texas +9 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +This page is intentionally left blank. +10 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +B Certification Results +The following results represent a summary of +● the Security Target of the sponsor for the Target of Evaluation, +● the relevant evaluation results from the evaluation facility, and +● complementary notes and stipulations of the certification body. +11 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +1 Executive Summary +The Target of Evaluation (TOE) is IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and AccessAgent Fix Pack 22. It is an +enterprise single-sign-on product for Microsoft Windows-based systems. The TOE +automatically, driven by rules, enters user credentials into credential-requesting +applications on behalf of the user once the user has successfully authenticated to the +TOE. The TOE further provides functions to audit user actions, protect the user's data and +manage these TOE security functions. +The Security Target [6] is the basis for this certification. It is not based on a certified +Protection Profile. +The TOE Security Assurance Requirements (SAR) are based entirely on the assurance +components defined in Part 3 of the Common Criteria (see part C or [1], Part 3 for details). +The TOE meets the assurance requirements of the Evaluation Assurance Level EAL 3 +augmented by ALC_FLR.1. +The TOE Security Functional Requirements (SFR) relevant for the TOE are outlined in the +Security Target [6], chapter 6.1. They are all selected from Common Criteria Part 2. Thus +the TOE is CC Part 2 conformant. +The TOE Security Functional Requirements are implemented by the following TOE +Security Functionality: +TOE Security Functionality Addressed issue +Audit Various components of the product generate audit events +which are stored in the IMS Server database. All user +application access logs are collated into the IMS Server's +audit log database. Each log record contains info related to +time and location from which a user accesses a certain +application. +Identification and Authentication The TOE supports an identification mechanism and an +authentication mechanism. The TOE maintains its own user +repository and performs user authentication against various +forms of authentication credentials stored in this repository +(stored in the IMS Server database). The user's ISAM E-SSO +Password is created when the account is first created (when +the user first sign's up). +User Data Protection The TOE supports a user data protection mechanism. The +TOE stores each user's credential data in a Wallet; one Wallet +per-user. A Wallet provides confidentiality and integrity +protection of the user credential data through the use of +cryptographic operations. All cryptographic operations are +performed by the Operational Environment. +Security management The TOE supports security function management +mechanisms. Role-based access control is used to protect +access to operations in the AccessAdmin and AccessAssistant +applications. +Table 1: TOE Security Functionalities +For more details please refer to the Security Target [6], chapter 7.1. +12 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +The assets to be protected by the TOE are defined in the Security Target [6], chapter 3.1. +Based on these assets the TOE Security Problem is defined in terms of Assumptions, +Threats and Organisational Security Policies. This is outlined in the Security Target [6], +chapter 3.1 - 3.3. +This certification covers the configurations of the TOE as outlined in chapter 8. +The vulnerability assessment results as stated within this certificate do not include a rating +for those cryptographic algorithms and their implementation suitable for encryption and +decryption (see BSIG Section 9, Para. 4, Clause 2). +The certification results only apply to the version of the product indicated in the certificate +and on the condition that all the stipulations are kept as detailed in this Certification +Report. This certificate is not an endorsement of the IT product by the Federal Office for +Information Security (BSI) or any other organisation that recognises or gives effect to this +certificate, and no warranty of the IT product by BSI or any other organisation that +recognises or gives effect to this certificate, is either expressed or implied. +2 Identification of the TOE +The Target of Evaluation (TOE) is called: +IBM Security Access Manager for Enterprise Single Sign-On, Version 8.2 +The following table outlines the TOE deliverables: +No Type Identifier Release Form of +Delivery +1 SW IBM Security Access Manager for Enterprise +Single Sign on Suite (32bit) +8.2.0, Part Number +CRH6SML +DL +2 SW IBM Security Access Manager for Enterprise +Single Sign on Suite (64bit) +8.2.0, Part Number CRH6TML DL +3 SW IMS Server Interim Fix 04 8.2.0 +(8.2.0-ISSSAMESSOIMSIF00 +04.zip) +DL +4 SW Access Agent Fixpack 22 (32bit) 8.2.0 +(8.2.0-ISSSAMESSOAAFP00 +22_32.msp) +DL +5 SW Access Agent Fixpack 22 (64bit) 8.2.0 +(8.2.0-ISSSAMESSOAAFP00 +22_64.msp) +DL +6 DOC IBM Security Access Manager for Enterprise +Single Sign-On Common Criteria Guide +8.2.0 (SC27-4365-00) DL +7 DOC IBM Security Access Manager for Enterprise +Single Sign-on Quick Start Guide +8.2.0 (GI11-8732-03) DL +8 DOC IBM Security Access Manager for Enterprise +Single Sign-on Installation Guide +8.2.0 (GI11-9309-01) DL +9 DOC IBM Security Access Manager for Enterprise +Single Sign-on Configuration Guide +8.2.0 (GC23-9692-01) DL +10 DOC IBM Security Access Manager for Enterprise +Single Sign-on Deployment Guide +8.2.0 (SC23-9952-03) DL +11 DOC IBM Security Access Manager for Enterprise +Single Sign-On Administrator Guide +8.2.0 (SC23-9951-03) DL +13 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +No Type Identifier Release Form of +Delivery +12 DOC IBM Security Access Manager for Enterprise +Single Sign-on User Guide +8.2.0 (SC23-9950-03) DL +13 DOC IBM Security Access Manager for Enterprise +Single Sign-on Help Desk Guide +8.2.0 (SC23-9953-03) DL +14 DOC IBM Security Access Manager for Enterprise +Single Sign-on Troubleshooting and Support +Guide +8.2.0 (GC23-9693-01) DL +15 DOC IBM Security Access Manager for Enterprise +Single Sign-on AccessStudio Guide +8.2.0 (SC23-9956-03) DL +16 DOC IBM Security Access Manager for Enterprise +Single Sign-On Policies Definition Guide +8.2.0 (SC23-9694-01) DL +17 DOC IBM Security Access Manager for Enterprise +Single Sign-on Provisioning Integration Guide +8.2.0 (SC23-9957-03) DL +18 DOC IBM Security Access Manager for Enterprise +Single Sign-On Web API for Credential +Management Guide +8.2.0 (SC14-7646-00) DL +19 DOC IBM Security Access Manager for Enterprise +Single Sign-on Context Management Integration +Guide +8.2.0 (SC23-9954-03) DL +20 DOC IBM Security Access Manager for Enterprise +Single Sign-On Serial ID SPI Guide +8.2.0 (SC14-7626-00) DL +21 DOC IBM Security Access Manager for Enterprise +Single Sign-On Lightweight AccessAgent mode +on Terminal Server SDK Guide +8.2.0 (SC14-7657-00) DL +22 DOC IBM Security Access Manager for Enterprise +Single Sign-On Error Message Reference +Guide +8.2.0 (GC14-7624-00) DL +Table 2: Deliverables of the TOE +The TOE is electronically downloaded using 2 steps: +1. The base version of the TOE is to be downloaded from passport advantage. +2. The TOE Fixpacks as well as the documentation is electronically downloaded from +the IBM support site. +The downloads are to be carried using the secure Download Director protocol. +The TOE can be identified by the user by its version numbers. The Access Agent version +number is: 8.2.0.3458. The IMS Version number is: 8.2.0.696 +3 Security Policy +The Security Policy is expressed by the set of Security Functional Requirements and +implemented by the TOE. It covers the following issues: +● Access Profiles: The TOE only releases a subset of the credential information +stored in a user's Wallet to the target application the user intends to identify and +authenticate to based on Access Profiles. +14 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +● Audit: The TOE shall offer an audit mechanism that can be used to hold users of +each role accountable for security-relevant actions performed with the TSF. +● Authentication: The TOE must ensure that only authorized users gain access to +the TOE and its resources. +● Manage: The TSF must provide all the functions and facilities necessary to support +the authorized users that are responsible for the management of TOE security +mechanisms and must ensure that only authorized users are able to access such +functionality. +● Role: The TOE must assign a role to each user after successful identification and +authentication to the management facility. This role limits the management actions +the user is allowed to perform. +● Password Quality: When in GINA mode with Active Directory password +synchronization disabled, the TOE must ensure that the quality of the ISAM E-SSO +Password protecting the Common Symmetric Key (CSK) must possess the strength +to prevent credential guessing from threat agents. +● Wallet Access: The TOE must ensure that users can only access the contents of +the Wallet assigned to them. +4 Assumptions and Clarification of Scope +The Assumptions defined in the Security Target and some aspects of Threats and +Organisational Security Policies are not covered by the TOE itself. These aspects lead to +specific security objectives to be fulfilled by the TOE-Environment. The following topics are +of relevance: +● Cryptographic operations +● Competent individuals +● Password quality +● Physical protection +● Runtime environment +● Time source +● Users +Details can be found in the Security Target [6], chapter 4.2. +5 Architectural Information +The TOE consists of multiple components executing in a distributed environment and +communicating using the network. Figure 1 in the Security Target [6] depicts the different +components forming the product. Each of the green shaded components are described in +the subsequent sections in the Security Target [6], chapter 1.5.2. These green shaded +components together form the TOE. +15 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +6 Documentation +The evaluated documentation as outlined in table 2 is being provided with the product to +the customer. This documentation contains the required information for secure usage of +the TOE in accordance with the Security Target. +Additional obligations and notes for secure usage of the TOE as outlined in chapter 10 of +this report have to be followed. +7 IT Product Testing +7.1 Developer Testing +The developer used 24 manual test cases where each test case may contain up to 100 +sub tests (each test testing a specific aspect of a functionality). +Two test scripts are used that automatically test several functions related to wallet and role +management. The developer test evidence comprises many more tests cases but the +majority of them is not relevant for the evaluated functions. +7.1.1 Test Configuration +The developer tested all supported agent and IMS server platforms: +● AccessAgent on Windows XP/7 on 32bit and 64 bit (it includes GSKit which is part +of the TOE environment) +● IMS server on Windows Server 2008 32bit and 64bit +● WebSphere 7 (which includes Java) for databases, IBM DB2, Microsoft SQL Server, +and Oracle Database has been tested +Other settings relevant for the evaluated configuration (e.g. password strength or +enable/disabling certain functions) have been only used when it is needed for the tests. +7.1.2 Test approach +The manual developer tests were designed to use the GUI (Access Agent or IMS server +web interfaces). The manual tests consists of several test plan documents where one +document refers to the regression testing. The regression testing is a large collection of +tests that have been collected over time for each new version of the product. This ensures +that old functions still work on the latest release version. +The automated tests use the IMS API which is an internal TOE interface to the IMS server. +7.1.3 Testing Results +The developer testing was performed successfully with no exceptions by the developer on +all supported platforms. +7.2 Evaluator Testing Effort +The evaluator chose 28 developer tests for independent testing and created 7 new test +cases. +16 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +7.2.1 Test Approach and Depth +The evaluator witnessed parts developer tests via a web conference, where a subset (9 +developer tests) of the developer tests were executed based on the evaluator's choice. +18 other developer tests and all but one evaluator test have been executed on in the +ITSEF lab where the TOE has been installed. The evaluator test which involves the use of +the AccessStudio for access profiles application was performed on the developer test +systems. +The evaluators choice of the developer tests was to test all security functions (apart from +the auditing) and to also see all different types of supported platforms working. Specifically, +the following areas are covered by the independent testing of developer tests: +● releasing credentials to web applications and non-web applications as the core +functionality of the single-sign on operations +● authentication of AccessAgent users and IMS administrators +● policy management by help desk and administrative user roles +● password management by users +For the evaluator tests, the focus lay on: +● audit generation and review, especially testing the interaction between the +AccessAgent and the IMS server so that audit events get exchanged +● AccessAgent authentication in case the respective AD user account gets changed +(e.g. disabled) or client installation is not part of the AD domain +● creation and application of access profiles (the access profile that was created as +part of this test was used as input to the penetration testing when attempting to +obtain user credentials by forging applications) +All subsystems have been tested: while the tests of the user authentication applied to the +AccessAgent, all management and admin authentication tests used the AccessAdmin and +AccessAssistant subsystems. The IMS runtime was tested indirectly by using the +AccessAgent because the agent uses the IMS server interface to communicate with the +server. The configuration utilities were tested too as part of the access profile upload and +TOE configuration steps. +7.2.2 Test Configuration +The evaluator test configuration was the following: +● two AccessAgent (FixPack 22) client machines with WinXP 32-bit as underlying +platform +● IMS (Interim Fix 4) server installation with Windows Server 2008 32-bit as +underlying platform +● Active Directory as User Registry +● Applied configuration according to the evaluate configuration in the guidance as +necessary for the testing +● IBM DB2 9.7 +The developer test setup consisted of a broader number of platforms (covering all +platforms that are defined for the evaluated configuration): +17 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +● AccessAgent: WinXP 32/64 bit, Windows 7 32/64 bit +● IMS Server: Windows Server 2008 32/64 bit +7.2.3 Test Results +All tests have been performed successfully with the actual results matching the expected +results. +7.3 Evaluator Penetration Testing +The evaluator used the CVE for finding publicly documented vulnerabilities. None of the +found entries required independent testing. +The test effort based on all the developer evidence lead to the test of 14 potential +vulnerabilities, where some vulnerabilities might apply to a number of different functions. +Therefore, several tests where subdivided into testing the vulnerability aspect on several +functions. +The test approach was to generally aiming at authentication and authorization functions of +the TOE, i.e., the IMS server that enforces these security functions. This has been +performed through attempting to gain access to TOE interfaces that should not be +externally accessible, or use functions with unexpected parameter values (e.g. the +AccessAgent uses the IMS server login functions by always providing the correct domain +identifier, which is not the case when crafting requests to the IMS server manually). +Considering the type of the security functions that were attempted to violate, the testing +can be divided into these effects: +Testing the usability of invisible/deprecated functions that may violate authentication TSF, +as well as standard authentication functions with ill-formed parameters. +Testing the usability of invisible/deprecated functions that may violate authorization TSF, +as well as standard authorization functions. +Implicit test of wallet integrity through manipulating wallet data and its effect on single sign +for application. A brute-force attack was tested to verify whether the SFR for verification of +secrets holds. +Other tests were not target against a specific security objective, but attempted to observe +any suspicious behavior as a result of the ill-formed input data tests, which could then be +further analyzed. +Another group of tests where used to spot any interface functions among the complex +SOAP and WebSphere provided interfaces, that are available despite being hidden from +the network view according to the FSP. Any unexpectedly available interface could be +used to violate management function requirements. +7.3.1 Test configuration +The tests were performed on the TOE that was installed on one of the supported +WebSphere Application Server 7.0 on a Microsoft Windows Server 2008 32-bit platform for +the IMS server and a Microsoft Windows XP client installation. The test configuration in +terms of the evaluated configuration settings and software versions was the same than for +the evaluator's independent testing (following the evaluated configuration defined in the +CC-specific guidance provided by the developer). +18 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +7.3.2 Results +The tests showed that a few more functions allow a password authentication but none of +the penetration tests revealed an exploitable vulnerability. +8 Evaluated Configuration +This certification covers the following configuration of the TOE: +● The use of personal secrets must be disabled. +● Only the AccessAgent plugins provided with the TOE are allowed. +● Only the ISAM E-SSO Password authentication factor is allowed. +● Second factor authentication is disallowed. +● Self-service policies: +● Self-service password reset must be disabled. +● Self-service authorization code issuance must be disabled. +● Self-service registration and bypass of 2nd factor must be disabled. +● Self-service registering of additional secrets during sign-up must be disabled. +● The IMS Server's master secret must be protected to only allow the Administrator +role access to it. +● One-Time Passwords (OTPs) must be disabled. +● Mobile ActiveCode (MAC) must be disabled. +● Roaming Desktops (i.e., the use of Microsoft Windows Terminal Server and Citrix +Presentation Server) must be disabled. +● RADIUS authentication must be disabled. +● Windows Fast User Switching must be disabled on Windows 7 systems running +AccessAgent. +● Private Desktop must be disabled on Windows XP systems running AccessAgent. +● Single sign-on to AccessAdmin when using Microsoft Internet Explorer must be +disabled. +● The IMS Server/application must be the only application running in the WebSphere +Application Server (WAS). +● The TOE's password synchronization option with Active Directory affects the +security of the TOE. Specifically, enabling password synchronization with Active +Directory will disable the TOE's ability to enforce password quality requirements. +● The feedback email settings in AccessAssistant and Web Workplace must not be +enabled. +19 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +9 Results of the Evaluation +9.1 CC specific results +The Evaluation Technical Report (ETR) [7] was provided by the ITSEF according to the +Common Criteria [1], the Methodology [2], the requirements of the Scheme [3] and all +interpretations and guidelines of the Scheme (AIS) [4] as relevant for the TOE. +The Evaluation Methodology CEM [2] was used. +As a result of the evaluation the verdict PASS is confirmed for the following assurance +components: +● All components of the EAL 3 package including the class ASE as defined in the CC (see +also part C of this report) +● The components ALC_FLR.1 augmented for this TOE evaluation. +The evaluation has confirmed: +● for the Functionality: Product specific Security Target +Common Criteria Part 2 conformant +● for the Assurance: Common Criteria Part 3 conformant +EAL 3 augmented by ALC_FLR.1 +The results of the evaluation are only applicable to the TOE as defined in chapter 2 and +the configuration as outlined in chapter 8 above. +9.2 Results of cryptographic assessment +The TOE does not include cryptographic mechanisms. Thus, no such mechanisms were +part of the assessment. +10 Obligations and Notes for the Usage of the TOE +The documents as outlined in table 2 contain necessary information about the usage of the +TOE and all security hints therein have to be considered. In addition all aspects of +Assumptions, Threats and OSPs as outlined in the Security Target not covered by the TOE +itself need to be fulfilled by the operational environment of the TOE. +The customer or user of the product shall consider the results of the certification within his +system risk management process. In order for the evolution of attack methods and +techniques to be covered, he should define the period of time until a re-assessment of the +TOE is required and thus requested from the sponsor of the certificate. +If available, certified updates of the TOE should be used. If non-certified updates or +patches are available the user of the TOE should request the sponsor to provide a +re-certification. In the meantime a risk management process of the system using the TOE +should investigate and decide on the usage of not yet certified updates and patches or +take additional measures in order to maintain system security. +11 Security Target +For the purpose of publishing, the Security Target [6] of the Target of Evaluation (TOE) is +provided within a separate document as Annex A of this report. +20 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +12 Definitions +12.1 Acronyms +AIS Application Notes and Interpretations of the Scheme +BSI Bundesamt für Sicherheit in der Informationstechnik / Federal Office for +Information Security, Bonn, Germany +BSIG BSI-Gesetz / Act on the Federal Office for Information Security +CCRA Common Criteria Recognition Arrangement +CC Common Criteria for IT Security Evaluation +CEM Common Methodology for Information Technology Security Evaluation +cPP Collaborative Protection Profile +EAL Evaluation Assurance Level +ETR Evaluation Technical Report +IT Information Technology +ITSEF Information Technology Security Evaluation Facility +PP Protection Profile +SAR Security Assurance Requirement +SFP Security Function Policy +SFR Security Functional Requirement +ST Security Target +TOE Target of Evaluation +TSF TOE Security Functionality +12.2 Glossary +Augmentation - The addition of one or more requirement(s) to a package. +Collaborative Protection Profile - A Protection Profile collaboratively developed by an +International Technical Community endorsed by the Management Committee. +Extension - The addition to an ST or PP of functional requirements not contained in CC +part 2 and/or assurance requirements not contained in CC part 3. +Formal - Expressed in a restricted syntax language with defined semantics based on +well-established mathematical concepts. +Informal - Expressed in natural language. +Object - A passive entity in the TOE, that contains or receives information, and upon which +subjects perform operations. +Package - named set of either security functional or security assurance requirements +Protection Profile - A formal document defined in CC, expressing an implementation +independent set of security requirements for a category of IT Products that meet specific +consumer needs. +21 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +Security Target - An implementation-dependent statement of security needs for a specific +identified TOE. +Semiformal - Expressed in a restricted syntax language with defined semantics. +Subject - An active entity in the TOE that performs operations on objects. +Target of Evaluation - An IT Product and its associated administrator and user guidance +documentation that is the subject of an Evaluation. +TOE Security Functionality - Combined functionality of all hardware, software, and +firmware of a TOE that must be relied upon for the correct enforcement of the SFRs. +22 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +13 Bibliography +[1] Common Criteria for Information Technology Security Evaluation, Version 3.1, +Part 1: Introduction and general model, Revision 3, July 2009 +Part 2: Security functional components, Revision 3, July 2009 +Part 3: Security assurance components, Revision 3, July 2009 +[2] Common Methodology for Information Technology Security Evaluation (CEM), +Evaluation Methodology, Version 3.1, Rev. 3, July 2009 +[3] BSI certification: Technical information on the IT security certification of products, +protection profiles and sites (BSI 7138) and Requirements regarding the Evaluation +Facility for the Evaluation of Products, Protection Profiles and Sites under the CC +and ITSEC (BSI 7125) +[4] Application Notes and Interpretations of the Scheme (AIS) as relevant for the TOE8 +. +[5] German IT Security Certificates (BSI 7148), periodically updated list published also +in the BSI Website +[6] Security Target BSI-DSZ-CC-0683-2014, Version 1.19, 2014-03-05, IBM Security +Access Manager for Enterprise Single Sign-On Version 8.2 with IMS Server Interim +Fix 4 and AccessAgent Fix Pack 22 Security Target, IBM Corporation +[7] Evaluation Technical Report, Version 2, 2014-09-22, Final Evaluation Technical +Report, atsec information security GmbH, (confidential document) +[8] CM Lists, file name: CM.LISTS.real-final-final-final.zip, Date: 2014-09-22 +[9] Security Access Manager for Enterprise Single Sign-On: Configuration Guide, +Version GC23-9692-01, Date: 2012-04-02 +8 +specifically +• AIS 1, Version 13, Durchführung der Ortsbesichtigung in der Entwicklungsumgebung des +Herstellers +• AIS 23, Version 3, Zusammentragen von Nachweisen der Entwickler (Collection of Developer +Evidence) +• AIS 32, Version 7, CC-Interpretationen im deutschen Zertifizierungsschema +23 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +This page is intentionally left blank. +24 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +C Excerpts from the Criteria +CC Part 1: +Conformance Claim (chapter 10.4) +“The conformance claim indicates the source of the collection of requirements that is met +by a PP or ST that passes its evaluation. This conformance claim contains a CC +conformance claim that: +● describes the version of the CC to which the PP or ST claims conformance. +● describes the conformance to CC Part 2 (security functional requirements) as either: +– CC Part 2 conformant - A PP or ST is CC Part 2 conformant if all SFRs in that +PP or ST are based only upon functional components in CC Part 2, or +– CC Part 2 extended - A PP or ST is CC Part 2 extended if at least one SFR in +that PP or ST is not based upon functional components in CC Part 2. +● describes the conformance to CC Part 3 (security assurance requirements) as either: +– CC Part 3 conformant - A PP or ST is CC Part 3 conformant if all SARs in that +PP or ST are based only upon assurance components in CC Part 3, or +– CC Part 3 extended - A PP or ST is CC Part 3 extended if at least one SAR in +that PP or ST is not based upon assurance components in CC Part 3. +Additionally, the conformance claim may include a statement made with respect to +packages, in which case it consists of one of the following: +● Package name Conformant - A PP or ST is conformant to a pre-defined package +(e.g. EAL) if: +– the SFRs of that PP or ST are identical to the SFRs in the package, or +– the SARs of that PP or ST are identical to the SARs in the package. +● Package name Augmented - A PP or ST is an augmentation of a predefined package +if: +– the SFRs of that PP or ST contain all SFRs in the package, but have at least +one additional SFR or one SFR that is hierarchically higher than an SFR in the +package. +– the SARs of that PP or ST contain all SARs in the package, but have at least +one additional SAR or one SAR that is hierarchically higher than an SAR in the +package. +Note that when a TOE is successfully evaluated to a given ST, any conformance claims of +the ST also hold for the TOE. A TOE can therefore also be e.g. CC Part 2 conformant. +Finally, the conformance claim may also include two statements with respect to Protection +Profiles: +● PP Conformant - A PP or TOE meets specific PP(s), which are listed as part of the +conformance result. +● Conformance Statement (Only for PPs) - This statement describes the manner in +which PPs or STs must conform to this PP: strict or demonstrable. For more +information on this Conformance Statement, see Annex D.” +25 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +CC Part 3: +Class APE: Protection Profile evaluation (chapter 10) +“Evaluating a PP is required to demonstrate that the PP is sound and internally consistent, +and, if the PP is based on one or more other PPs or on packages, that the PP is a correct +instantiation of these PPs and packages. These properties are necessary for the PP to be +suitable for use as the basis for writing an ST or another PP. +Assurance Class Assurance Components +Class APE: Protection +Profile evaluation +APE_INT.1 PP introduction +APE_CCL.1 Conformance claims +APE_SPD.1 Security problem definition +APE_OBJ.1 Security objectives for the operational environment +APE_OBJ.2 Security objectives +APE_ECD.1 Extended components definition +APE_REQ.1 Stated security requirements +APE_REQ.2 Derived security requirements +APE: Protection Profile evaluation class decomposition” +Class ASE: Security Target evaluation (chapter 11) +“Evaluating an ST is required to demonstrate that the ST is sound and internally +consistent, and, if the ST is based on one or more PPs or packages, that the ST is a +correct instantiation of these PPs and packages. These properties are necessary for the +ST to be suitable for use as the basis for a TOE evaluation.” +Assurance Class Assurance Components +Class ASE: Security +Target evaluation +ASE_INT.1 ST introduction +ASE_CCL.1 Conformance claims +ASE_SPD.1 Security problem definition +ASE_OBJ.1 Security objectives for the operational environment +ASE_OBJ.2 Security objectives +ASE_ECD.1 Extended components definition +ASE_REQ.1 Stated security requirements +ASE_REQ.2 Derived security requirements +ASE_TSS.1 TOE summary specification +ASE_TSS.2 TOE summary specification with architectural design +summary +ASE: Security Target evaluation class decomposition +26 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +Security assurance components (chapter 7) +“The following Sections describe the constructs used in representing the assurance +classes, families, and components.“ +“Each assurance class contains at least one assurance family.” +“Each assurance family contains one or more assurance components.” +The following table shows the assurance class decomposition. +Assurance Class Assurance Components +ADV: Development ADV_ARC.1 Security architecture description +ADV_FSP.1 Basic functional specification +ADV_FSP.2 Security-enforcing functional specification +ADV_FSP.3 Functional specification with complete summary +ADV_FSP.4 Complete functional specification +ADV_FSP.5 Complete semi-formal functional specification with +additional error information +ADV_FSP.6 Complete semi-formal functional specification with +additional formal specification +ADV_IMP.1 Implementation representation of the TSF +ADV_IMP.2 Implementation of the TSF +ADV_INT.1 Well-structured subset of TSF internals +ADV_INT.2 Well-structured internals +ADV_INT.3 Minimally complex internals +ADV_SPM.1 Formal TOE security policy model +ADV_TDS.1 Basic design +ADV_TDS.2 Architectural design +ADV_TDS.3 Basic modular design +ADV_TDS.4 Semiformal modular design +ADV_TDS.5 Complete semiformal modular design +ADV_TDS.6 Complete semiformal modular design with formal +high-level design presentation +AGD: +Guidance documents +AGD_OPE.1 Operational user guidance +AGD_PRE.1 Preparative procedures +ALC: Life cycle support +ALC_CMC.1 Labelling of the TOE +ALC_CMC.2 Use of a CM system +ALC_CMC.3 Authorisation controls +ALC_CMC.4 Production support, acceptance procedures and +automation +ALC_CMC.5 Advanced support +ALC_CMS.1 TOE CM coverage +ALC_CMS.2 Parts of the TOE CM coverage +ALC_CMS.3 Implementation representation CM coverage +ALC_CMS.4 Problem tracking CM coverage +ALC_CMS.5 Development tools CM coverage +ALC_DEL.1 Delivery procedures +ALC_DVS.1 Identification of security measures +ALC_DVS.2 Sufficiency of security measures +ALC_FLR.1 Basic flaw remediation +ALC_FLR.2 Flaw reporting procedures +ALC_FLR.3 Systematic flaw remediation +ALC_LCD.1 Developer defined life-cycle model +27 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +Assurance Class Assurance Components +ALC_LCD.2 Measurable life-cycle model +ALC_TAT.1 Well-defined development tools +ALC_TAT.2 Compliance with implementation standards +ALC_TAT.3 Compliance with implementation standards - all parts +ATE: Tests +ATE_COV.1 Evidence of coverage +ATE_COV.2 Analysis of coverage +ATE_COV.3 Rigorous analysis of coverage +ATE_DPT.1 Testing: basic design +ATE_DPT.2 Testing: security enforcing modules +ATE_DPT.3 Testing: modular design +ATE_DPT.4 Testing: implementation representation +ATE_FUN.1 Functional testing +ATE_FUN.2 Ordered functional testing +ATE_IND.1 Independent testing – conformance +ATE_IND.2 Independent testing – sample +ATE_IND.3 Independent testing – complete +AVA: Vulnerability +assessment +AVA_VAN.1 Vulnerability survey +AVA_VAN.2 Vulnerability analysis +AVA_VAN.3 Focused vulnerability analysis +AVA_VAN.4 Methodical vulnerability analysis +AVA_VAN.5 Advanced methodical vulnerability analysis +Assurance class decomposition +Evaluation assurance levels (chapter 8) +“The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the +level of assurance obtained with the cost and feasibility of acquiring that degree of +assurance. The CC approach identifies the separate concepts of assurance in a TOE at +the end of the evaluation, and of maintenance of that assurance during the operational use +of the TOE. +It is important to note that not all families and components from CC Part 3 are included in +the EALs. This is not to say that these do not provide meaningful and desirable +assurances. Instead, it is expected that these families and components will be considered +for augmentation of an EAL in those PPs and STs for which they provide utility.” +Evaluation assurance level (EAL) overview (chapter 8.1) +“Table 1 represents a summary of the EALs. The columns represent a hierarchically +ordered set of EALs, while the rows represent assurance families. Each number in the +resulting matrix identifies a specific assurance component where applicable. +As outlined in the next Section, seven hierarchically ordered evaluation assurance levels +are defined in the CC for the rating of a TOE's assurance. They are hierarchically ordered +inasmuch as each EAL represents more assurance than all lower EALs. The increase in +assurance from EAL to EAL is accomplished by substitution of a hierarchically higher +assurance component from the same assurance family (i.e. increasing rigour, scope, +and/or depth) and from the addition of assurance components from other assurance +families (i.e. adding new requirements). +These EALs consist of an appropriate combination of assurance components as described +in Chapter 7 of this CC Part 3. More precisely, each EAL includes no more than one +28 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +component of each assurance family and all assurance dependencies of every component +are addressed. +While the EALs are defined in the CC, it is possible to represent other combinations of +assurance. Specifically, the notion of “augmentation” allows the addition of assurance +components (from assurance families not already included in the EAL) or the substitution +of assurance components (with another hierarchically higher assurance component in the +same assurance family) to an EAL. Of the assurance constructs defined in the CC, only +EALs may be augmented. The notion of an “EAL minus a constituent assurance +component” is not recognised by the standard as a valid claim. Augmentation carries with +it the obligation on the part of the claimant to justify the utility and added value of the +added assurance component to the EAL. An EAL may also be augmented with extended +assurance requirements. +Evaluation assurance level 1 (EAL 1) - functionally tested (chapter 8.3) +“Objectives +EAL 1 is applicable where some confidence in correct operation is required, but the threats +to security are not viewed as serious. It will be of value where independent assurance is +required to support the contention that due care has been exercised with respect to the +protection of personal or similar information. +EAL 1 requires only a limited security target. It is sufficient to simply state the SFRs that +the TOE must meet, rather than deriving them from threats, OSPs and assumptions +through security objectives. +EAL 1 provides an evaluation of the TOE as made available to the customer, including +independent testing against a specification, and an examination of the guidance +documentation provided. It is intended that an EAL 1 evaluation could be successfully +conducted without assistance from the developer of the TOE, and for minimal outlay. +An evaluation at this level should provide evidence that the TOE functions in a manner +consistent with its documentation.” +Evaluation assurance level 2 (EAL 2) - structurally tested (chapter 8.4) +“Objectives +EAL 2 requires the co-operation of the developer in terms of the delivery of design +information and test results, but should not demand more effort on the part of the +developer than is consistent with good commercial practise. As such it should not require a +substantially increased investment of cost or time. +EAL 2 is therefore applicable in those circumstances where developers or users require a +low to moderate level of independently assured security in the absence of ready +availability of the complete development record. Such a situation may arise when securing +legacy systems, or where access to the developer may be limited.” +Evaluation assurance level 3 (EAL 3) - methodically tested and checked (chapter 8.5) +“Objectives +EAL 3 permits a conscientious developer to gain maximum assurance from positive +security engineering at the design stage without substantial alteration of existing sound +development practises. +29 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +EAL 3 is applicable in those circumstances where developers or users require a moderate +level of independently assured security, and require a thorough investigation of the TOE +and its development without substantial re-engineering.” +Evaluation assurance level 4 (EAL 4) - methodically designed, tested, and reviewed +(chapter 8.6) +“Objectives +EAL 4 permits a developer to gain maximum assurance from positive security engineering +based on good commercial development practises which, though rigorous, do not require +substantial specialist knowledge, skills, and other resources. EAL 4 is the highest level at +which it is likely to be economically feasible to retrofit to an existing product line. +EAL 4 is therefore applicable in those circumstances where developers or users require a +moderate to high level of independently assured security in conventional commodity TOEs +and are prepared to incur additional security-specific engineering costs.” +Evaluation assurance level 5 (EAL 5) - semiformally designed and tested (chapter +8.7) +“Objectives +EAL 5 permits a developer to gain maximum assurance from security engineering based +upon rigorous commercial development practises supported by moderate application of +specialist security engineering techniques. Such a TOE will probably be designed and +developed with the intent of achieving EAL 5 assurance. It is likely that the additional costs +attributable to the EAL 5 requirements, relative to rigorous development without the +application of specialised techniques, will not be large. +EAL 5 is therefore applicable in those circumstances where developers or users require a +high level of independently assured security in a planned development and require a +rigorous development approach without incurring unreasonable costs attributable to +specialist security engineering techniques.” +Evaluation assurance level 6 (EAL 6) - semiformally verified design and tested +(chapter 8.8) +“Objectives +EAL 6 permits developers to gain high assurance from application of security engineering +techniques to a rigorous development environment in order to produce a premium TOE for +protecting high value assets against significant risks. +EAL 6 is therefore applicable to the development of security TOEs for application in high +risk situations where the value of the protected assets justifies the additional costs.” +Evaluation assurance level 7 (EAL 7) - formally verified design and tested +(chapter 8.9) +“Objectives +EAL 7 is applicable to the development of security TOEs for application in extremely high +risk situations and/or where the high value of the assets justifies the higher costs. Practical +application of EAL 7 is currently limited to TOEs with tightly focused security functionality +that is amenable to extensive formal analysis.” +30 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +Assurance +Class +Assurance +Family +Assurance Components by +Evaluation Assurance Level +EAL 1 EAL 2 EAL 3 EAL 4 EAL 5 EAL 6 EAL 7 +Development ADV_ARC 1 1 1 1 1 1 +ADV_FSP 1 2 3 4 5 5 6 +ADV_IMP 1 1 2 2 +ADV_INT 2 3 3 +ADV_SPM 1 1 +ADV_TDS 1 2 3 4 5 6 +Guidance +Documents +AGD_OPE 1 1 1 1 1 1 1 +AGD_PRE 1 1 1 1 1 1 1 +Life cycle +Support +ALC_CMC 1 2 3 4 4 5 5 +ALC_CMS 1 2 3 4 5 5 5 +ALC_DEL 1 1 1 1 1 1 +ALC_DVS 1 1 1 2 2 +ALC_FLR +ALC_LCD 1 1 1 1 2 +ALC_TAT 1 2 3 3 +Security Target +Evaluation +ASE_CCL 1 1 1 1 1 1 1 +ASE_ECD 1 1 1 1 1 1 1 +ASE_INT 1 1 1 1 1 1 1 +ASE_OBJ 1 2 2 2 2 2 2 +ASR_REQ 1 2 2 2 2 2 2 +ASE_SPD 1 1 1 1 1 1 +ASE_TSS 1 1 1 1 1 1 1 +Tests ATE_COV 1 2 2 2 3 3 +ATE_DPT 1 1 3 3 4 +ATE_FUN 1 1 1 1 2 2 +ATE_IND 1 2 2 2 2 2 3 +Vulnerability +assessment +AVA_VAN 1 2 2 3 4 5 5 +Table 1: Evaluation assurance level summary” +31 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +Class AVA: Vulnerability assessment (chapter 16) +“The AVA: Vulnerability assessment class addresses the possibility of exploitable +vulnerabilities introduced in the development or the operation of the TOE.” +Vulnerability analysis (AVA_VAN) (chapter 16.1) +“Objectives +Vulnerability analysis is an assessment to determine whether potential vulnerabilities +identified, during the evaluation of the development and anticipated operation of the TOE +or by other methods (e.g. by flaw hypotheses or quantitative or statistical analysis of the +security behaviour of the underlying security mechanisms), could allow attackers to violate +the SFRs. +Vulnerability analysis deals with the threats that an attacker will be able to discover flaws +that will allow unauthorised access to data and functionality, allow the ability to interfere +with or alter the TSF, or interfere with the authorised capabilities of other users.” +32 / 34 + BSI-DSZ-CC-0683-2014 Certification Report +D Annexes +List of annexes of this certification report +Annex A: Security Target provided within a separate document. +33 / 34 + Certification Report BSI-DSZ-CC-0683-2014 +This page is intentionally left blank. +34 / 34 + \ No newline at end of file diff --git a/tests/data/cc/analysis/certs/targets/pdf/ebd276cca70fd723.pdf b/tests/data/cc/analysis/certs/targets/pdf/ebd276cca70fd723.pdf deleted file mode 100644 index e1e463f4..00000000 Binary files a/tests/data/cc/analysis/certs/targets/pdf/ebd276cca70fd723.pdf and /dev/null differ diff --git a/tests/data/cc/analysis/certs/targets/pdf/ed91ff3e658457fd.pdf b/tests/data/cc/analysis/certs/targets/pdf/ed91ff3e658457fd.pdf new file mode 100644 index 00000000..e1e463f4 Binary files /dev/null and b/tests/data/cc/analysis/certs/targets/pdf/ed91ff3e658457fd.pdf differ diff --git a/tests/data/cc/analysis/certs/targets/txt/ebd276cca70fd723.txt b/tests/data/cc/analysis/certs/targets/txt/ebd276cca70fd723.txt deleted file mode 100644 index fc0c022a..00000000 --- a/tests/data/cc/analysis/certs/targets/txt/ebd276cca70fd723.txt +++ /dev/null @@ -1,2168 +0,0 @@ -IBM Security Access Manager for Enterprise -Single Sign-On Version 8.2 with IMS Server -Interim Fix 4 and AccessAgent Fix Pack 22 -Security Target -1.19 -Version: -Released -Status: -2014-03-05 -Last Update: - Trademarks -IBM and the IBM logo are trademarks or registered trademarks of International Business Machines -Corporation in the United States, other countries, or both. -The following terms are trademarks of International Business Machines Corporation in the United -States, other countries, or both: -● DB2® -● WebSphere® -The following terms are trademarks of Oracle Corporation: -● Java® -● Oracle® -The following terms are trademarks of Microsoft Corporation: -● Active Directory® -● SQL Server® -● Windows® -● Windows Server® -Legal Notice -This document is provided AS IS with no express or implied warranties. Use the information in this -document at your own risk. -This document may be reproduced or distributed in any form without prior permission provided the -copyright notice is retained on all copies. Modified versions of this document may be freely distributed -provided that they are clearly identified as such, and this copyright is included intact. -Revision History -Changes to Previous Revision -Author(s) -Date -Revision -Initial ST. -Scott Chapman -2014-03-05 -1.19 -Page 2 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Table of Contents -1 Introduction .................................................................................................... 7 -1.1 Security Target Identification ......................................................................................... 7 -1.2 TOE Identification .......................................................................................................... 7 -1.3 TOE Type ....................................................................................................................... 7 -1.4 TOE Overview ................................................................................................................ 7 -1.4.1 Required non-TOE software .................................................................................. 7 -1.4.2 Intended method of use ........................................................................................ 8 -1.4.3 Major security features ......................................................................................... 8 -1.5 TOE Description ............................................................................................................. 8 -1.5.1 Introduction ........................................................................................................... 8 -1.5.2 Architecture .......................................................................................................... 9 -1.5.2.1 Communications ........................................................................................... 9 -1.5.2.2 The IMS Server ........................................................................................... 10 -1.5.2.3 AccessAgent ............................................................................................... 11 -1.5.2.4 AccessAdmin .............................................................................................. 12 -1.5.2.5 AccessAssistant .......................................................................................... 12 -1.5.2.6 IMS Configuration Utility ............................................................................. 13 -1.5.3 TOE boundaries ................................................................................................... 13 -1.5.3.1 Physical ...................................................................................................... 13 -1.5.3.2 Logical ........................................................................................................ 14 -1.5.3.3 Evaluated configuration ............................................................................. 14 -1.5.4 Security policy model .......................................................................................... 15 -2 CC Conformance Claim ................................................................................... 16 -3 Security Problem Definition ............................................................................ 17 -3.1 Threat Environment ..................................................................................................... 17 -3.1.1 Threats countered by the TOE ............................................................................ 17 -3.2 Assumptions ................................................................................................................ 18 -3.2.1 Environment of use of the TOE ........................................................................... 18 -3.2.1.1 Physical ...................................................................................................... 18 -3.2.1.2 Personnel .................................................................................................... 18 -3.2.1.3 Logical ........................................................................................................ 18 -3.3 Organizational Security Policies ................................................................................... 19 -4 Security Objectives ........................................................................................ 20 -4.1 Objectives for the TOE ................................................................................................. 20 -4.2 Objectives for the Operational Environment ................................................................ 20 -4.3 Security Objectives Rationale ...................................................................................... 21 -4.3.1 Security objectives coverage .............................................................................. 21 -4.3.2 Security objectives sufficiency ............................................................................ 22 -5 Extended Components Definition .................................................................... 26 -6 Security Requirements ................................................................................... 27 -6.1 TOE Security Functional Requirements ........................................................................ 27 -Page 3 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 6.1.1 Security audit (FAU) ............................................................................................ 28 -6.1.1.1 Audit data generation (FAU_GEN.1) .......................................................... 28 -6.1.1.2 User identity association (FAU_GEN.2) ...................................................... 28 -6.1.1.3 Audit review (FAU_SAR.1) .......................................................................... 28 -6.1.1.4 Restricted audit review (FAU_SAR.2) ......................................................... 28 -6.1.1.5 Protected audit trail storage (FAU_STG.1) ................................................. 29 -6.1.2 User data protection (FDP) .................................................................................. 29 -6.1.2.1 Subset access control (FDP_ACC.2) ........................................................... 29 -6.1.2.2 Security attribute based access control (FDP_ACF.1) ................................ 30 -6.1.3 Identification and authentication (FIA) ................................................................ 30 -6.1.3.1 User attribute definition (FIA_ATD.1) ......................................................... 30 -6.1.3.2 Verification of secrets (FIA_SOS.1) ............................................................ 30 -6.1.3.3 User authentication before any action (FIA_UAU.2) ................................... 31 -6.1.3.4 User identification before any action (FIA_UID.2) ...................................... 31 -6.1.3.5 User-subject binding (FIA_USB.1) .............................................................. 31 -6.1.4 Security management (FMT) ............................................................................... 31 -6.1.4.1 Management of security attributes (FMT_MSA.1) ...................................... 31 -6.1.4.2 Static attribute initialisation (FMT_MSA.3) ................................................. 32 -6.1.4.3 Management of TSF data (FMT_MTD.1) ..................................................... 32 -6.1.4.4 Specification of management functions (FMT_SMF.1) ............................... 32 -6.1.4.5 Security roles (FMT_SMR.1) ....................................................................... 32 -6.2 Security Functional Requirements Rationale ............................................................... 33 -6.2.1 Security requirements coverage ......................................................................... 33 -6.2.2 Security requirements sufficiency ....................................................................... 33 -6.2.3 Security requirements dependency analysis ...................................................... 34 -6.3 Security Assurance Requirements ............................................................................... 36 -6.4 Security Assurance Requirements Rationale ............................................................... 37 -7 TOE Summary Specification ............................................................................ 38 -7.1 TOE Security Functionality ........................................................................................... 38 -7.1.1 Audit .................................................................................................................... 38 -7.1.2 Identification and authentication (I&A) ............................................................... 39 -7.1.2.1 AccessAgent ............................................................................................... 39 -7.1.2.2 AccessAssistant .......................................................................................... 40 -7.1.2.3 AccessAdmin .............................................................................................. 40 -7.1.2.4 IMS Configuration Utility ............................................................................. 40 -7.1.3 User data protection ........................................................................................... 41 -7.1.4 Security management ......................................................................................... 42 -8 Abbreviations, Terminology and References .................................................... 44 -8.1 Abbreviations ............................................................................................................... 44 -8.2 Terminology ................................................................................................................. 45 -8.3 References ................................................................................................................... 46 -Page 4 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - List of Tables -Table 1: Required Fix Packs .................................................................................................. 13 -Table 2: Mapping of security objectives to threats and policies ........................................... 22 -Table 3: Mapping of security objectives for the Operational Environment to assumptions, -threats and policies ........................................................................................................ 22 -Table 4: Sufficiency of objectives countering threats ........................................................... 23 -Table 5: Sufficiency of objectives holding assumptions ....................................................... 23 -Table 6: Sufficiency of objectives enforcing Organizational Security Policies ....................... 25 -Table 7: Security functional requirements for the TOE ......................................................... 27 -Table 8: Wallet Access Control Policy ................................................................................... 29 -Table 9: Wallet Access Control Policy management ............................................................. 31 -Table 10: TSF data management ......................................................................................... 32 -Table 11: Mapping of security functional requirements to security objectives ..................... 33 -Table 12: Security objectives for the TOE rationale ............................................................. 34 -Table 13: TOE SFR dependency analysis .............................................................................. 35 -Table 14: Security assurance requirements ......................................................................... 36 -Page 5 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - List of Figures -Figure 1: TOE Component Relationships ................................................................................ 9 -Figure 2: TOE Dataflow ......................................................................................................... 10 -Page 6 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 1 Introduction -1.1 Security Target Identification -IBM Security Access Manager for Enterprise Single Sign-On Version 8.2 with -IMS Server Interim Fix 4 and AccessAgent Fix Pack 22 Security Target -Title: -1.19 -Version: -Released -Status: -2014-03-05 -Date: -International Business Machines, Corporation -Sponsor: -International Business Machines, Corporation -Developer: -BSI -Certification Body: -BSI-DSZ-CC-0683 -Certification ID: -Security Access Manager, Enterprise Single Sign-On -Keywords: -1.2 TOE Identification -The TOE is IBM Security Access Manager for Enterprise Single Sign-On Version 8.2 with IMS Server -Interim Fix 4 and AccessAgent Fix Pack 22. -1.3 TOE Type -The TOE type is an enterprise single sign-on product for Microsoft Windows-based systems and -consists of software and guidance documentation. -1.4 TOE Overview -The Target of Evaluation (TOE) provides enterprises with single sign-on services, coupled with -strong authentication and comprehensive auditing capabilities. The TOE keeps track of each user's -application credentials (ID/password) in a credential Wallet, and helps users log onto the various -applications. This is achieved through a client-side software "agent" called the AccessAgent that, -in addition to automating application logons, provides application access audit logging. An important -characteristic of the TOE is that this agent emulates the logon actions of the user using the -application native logon interfaces – as such, it will work with applications as-is, without requiring -any applications to be re-programmed or re-configured. The TOE includes a central server called -the IMS (Integrated Management System) Server for storing user Wallets and for providing centralized -management of users and policies. -1.4.1 Required non-TOE software -The Operational Environment for the TOE consists of the following required software products: -● Microsoft Windows XP and Windows 7 for the AccessAgents (32-bit and 64-bit Windows) -● Microsoft Windows Server 2008 (32-bit/64-bit) for the IMS Server -● Microsoft Active Directory (AD) -● WebSphere Application Server (WAS) 7.0 (32-bit only) required by the IMS Server -● One of the following SQL-based databases required by the IMS Server: -❍ IBM DB2 -Page 7 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - ❍ Microsoft SQL Server -❍ Oracle Database -● Java Runtime Environment (IBM Java 6 for WAS 7.0) -● IBM Global Security Kit (GSKit) version 8.0.14.21 required by the AccessAgent. -1.4.2 Intended method of use -The TOE is intended to be used in a distributed Microsoft Windows environment for the automatic -authentication of users to applications. The TOE components use network security protocols (i.e., -SSL, TLS) to protect network data from disclosure and modification when communicating between -one another, so network eavesdropping attacks on TOE communication data is significantly -diminished. (The network security protocols and all cryptographic operations used by the protocols -including random number generation are provided by the Operational Environment.) -1.4.3 Major security features -The main security functions of the TOE are: -● Audit - Generation and review of audit records -● I&A - The identification and authentication of all users (regardless of their role) -● User data protection - Protection of user data stored within Wallets -● Security management - Role-based management of security behavior of the TOE -1.5 TOE Description -1.5.1 Introduction -The TOE is an enterprise single sign-on product for Microsoft Windows-based systems and consists -of software and guidance documentation. -The TOE automatically enters user credentials into credential-requesting applications on behalf of -the user once the user has successfully authenticated to the TOE. -For every user, the TOE maintains a set of application-to-user-credential mappings in a secure -Wallet. Each Wallet is encrypted with a Common Symmetric Key (CSK) which is uniquely generated -for each user. (The encryption operations and CSK key generation are performed by the Operational -Environment at the request of the TOE. The TOE controls the flow of the cryptographic operations -performed by the Operational Environment.) A more detailed description of Wallets and CSKs is -provided in section 7.1.3. -The TOE contains several types of access policies that are used as configuration data by the TOE. -These access policies are grouped into the following major categories: -● Machine policies - policies that affect a specific machine/computer (e.g., audit logging -policies, desktop inactivity policies, some Wallet policies). -● System policies - policies applicable to all users and machines (e.g., auditing policies, -password strength policies, some Wallet policies). -● User policies - policies that affect a specific user (e.g., Log on/Log off policies, some Wallet -policies). -Of the policies referred to above, only the password strength policies are evaluated by this evaluation. -Page 8 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - The TOE supports user role-based access control. Role-based access control is used to restrict user -access to certain TOE operations. The TOE implements the following user roles which are referred -to in the follow-on sections (for more detailed role descriptions, see section 7.1.4): -● Administrator -● Help desk -● User -1.5.2 Architecture -The TOE consists of multiple components executing in a distributed environment and communicating -using the network. Figure 1 depicts the different components forming the product. Each of the -green shaded components will be described in the subsequent sections. These green shaded -components together form the TOE. -Figure 1: TOE Component Relationships -1.5.2.1 Communications -The relevant communication relationships for the TOE are shown in figure 2. -Page 9 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Figure 2: TOE Dataflow -1.5.2.2 The IMS Server -The IMS (Integrated Management System) Server serves as the central repository and management -point for all system and user data consumed by the AccessAgents. The IMS Server performs the -following functions: -● Serves as a central repository and distribution point for AccessProfiles and other system -data. -● Serves as a central repository for all user data, including his credential Wallet and various -authentication and access policies. -● Provides an internal SOAP API for AccessAgents, as well as AccessAssistant servers, to -authenticate users, and to retrieve and synchronize system and user data. -● Provides Directory Connector SPI (not externalized) to enable integration with various user -repositories. Refer to the IBM Security Access Manager for Enterprise Single Sign-On 8.2 -RCS for the list of out of the box connectors that are provided. -● Provides a web-based UI (called "AccessAdmin") for managing users, machines and system -policies, as well as to query audit logs. -● Creates a user's initial Wallet (including a CSK generated by the Operational Environment -at the TOE's request) when a user account is created via the IMS Server. -Page 10 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Please note that the IMS DB (database) specifically marked in the illustration stores the data -managed by the IMS Server, but the database system is not part of the TOE. -The TOE's IMS Server requires the use of the Microsoft Active Directory directory server in the -evaluated configuration. The TOE can be configured to support password synchronization with -Active Directory. When password synchronization with Active Directory is enabled, the Active -Directory's password quality requirements are enforced by Active Directory, not the TOE. When -password synchronization with Active Directory is disabled, the TOE's password quality requirements -are enforced. -1.5.2.3 AccessAgent -The AccessAgent (AA) is the client software that is installed onto all Windows workstations at the -TOE deployment site, and configured to connect to the designated IMS Server. The AccessAgent -performs the following actions: -● Authenticates the end-user. Optionally, the AccessAgent protects access to the Windows -desktop by replacing the native Microsoft Graphical Identification and Authentication (GINA) -with the IBM Security Access Manager for Enterprise Single Sign-On GINA. -● Performs automated sign-on and sign-off to various applications. The AccessAgent has an -Observer module that is hooked into various applications, and which consults the appropriate -AccessProfile to perform the necessary logon/logoff and automation actions. The -AccessAgent will log onto applications using the appropriate application credential retrieved -from the user's credential Wallet. -● Tracks user application access activities and submits such audit events to the IMS Server. -● Synchronizes AccessProfiles, user's credential Wallet, and various Policy settings with the -IMS Server. -● Provides a UI for end-users to manage the application credentials stored in their credential -Wallet. -● Provides a UI for end-users to manage their own ISAM E-SSO Password. -● Creates a user's initial Wallet (including a CSK generated by the Operational Environment) -when a user sign's up through the AccessAgent. -The AccessAgent can be deployed to Windows workstations with or without GINA replacement (i.e., -in GINA mode or in GINA-less mode). In GINA mode, a user logs on to the IBM Security Access -Manager for Enterprise Single Sign-On (ISAM E-SSO) GINA using his ISAM E-SSO username and -password, whereupon the AccessAgent auto-logons to the Microsoft GINA with the user's Windows -username and password. In GINA-less mode, a user will log on to Windows through the regular -Microsoft GINA with his operating system username and password first, and the AccessAgent will -then use the same credentials to log on the user to his cached Wallet and to the IMS Server. -The AccessAgent will contact the IMS Server upon start up, upon each user logon, as well as on -periodic intervals, to synchronize system and user data changes with the server. However, the -AccessAgent could cache data locally onto the hard disk. As such, it is able to perform most of its -functions even if it is offline to the IMS Server at any point in time. -The AccessAgent relies on its Observer sub-module to perform its single sign-on and workflow -automation features. -The Observer module is composed of an Observer Core module and a number of Observer agent -instances that are hooked (through Windows APIs) into every Windows application (e.g. Lotus Notes, -Outlook, Internet Explorer, etc) launched. -Page 11 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - The behavior of the Observer agent within each specific Application is driven by a set of behavioral -specifications called an AccessProfile. Each AccessProfile is an XML structure (based on a custom -XML language) that provides a declarative set of preconditions (such as the signature of an -application – e.g. name and version of the EXE file), a set of behavioral states (e.g. pre-logon, -post-logon), and with each state, a set of triggers (e.g. when a specific screen is displayed) and -actions (e.g. auto-fill username into a certain field) for the Observer agent to watch for and execute -accordingly. -The Observer agents retrieve the required AccessProfiles as well as user credentials from the -Observer Core module, which in turn communicates with the rest of the AccessAgent for data -synchronization and session management services. -The AccessAgent controls access to a user's Wallet credentials so that only the application specified -by the AccessProfile obtains the user's credentials specified for that application. This Wallet Access -Control Policy is modeled in section 6.1.2.1 and is unique to the AccessAgent. The IMS Server and -other TOE components provide only a supporting role for this policy. -The AccessAgent creates the initial Wallet for a new user when the user sign's up through the -AccessAgent. The Wallet is used to hold the user's credentials for accessing other applications. The -contents of the Wallet are encrypted by the Operational Environment at the request of the TOE -using a 128 bit Common Symmetric Key (CSK). The generation of the CSK is also performed by the -Operational Environment at the request of the TOE. The CSK is encrypted by the Operational -Environment at the request of the TOE with the user's ISAM E-SSO Password and then stored with -the Wallet in a file called a Cryptobox. -AccessAgent allows each user to change his own ISAM E-SSO Password. The TOE's password strength -policies are enforced only when the AccessAgent is in GINA mode with Active Directory password -synchronization disabled. When in GINA-less mode or when Active Directory password synchronization -is enabled, the Active Directory's password strength policy is enforced by Active Directory, not the -TOE. -1.5.2.4 AccessAdmin -The AccessAdmin application is the web-based management console used to administer the IMS -Server, and to manage users (including modifying the role of each user) and policies. -The AccessAdmin application is installed with the IMS Server and allows the Administrator role to: -● Manage user authentication factors. (Only password authentication is allowed in the -evaluated configuration.) -● Manage system, machine, and user policies. -● Manage machine and user groupings. -● Query audit logs; or generate out of the box audit reports -The AccessAdmin application is also used by the Help desk role to: -● Manage user authentication factors. -● Manage user policies. -1.5.2.5 AccessAssistant -The AccessAssistant is the web-based interface used to provide password self-help to end-users. -In the evaluated configuration, it allows a user to: -Page 12 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - ● View and manage passwords for the various application accounts stored in the user's -Wallet. -The AccessAssistant is implemented as a set of servlets that is by default deployed on the IMS -Server. -1.5.2.6 IMS Configuration Utility -The IMS Configuration Utility is the web-based interface used to manage the configuration of the -IMS Server. The IMS Configuration Utility application is installed with the IMS Server and allows the -Administrator role to: -● Manage AccessProfiles -● Manage directory server configurations -● Manage database configurations -1.5.3 TOE boundaries -1.5.3.1 Physical -The TOE is comprised of the following components: -● IMS Server -● AccessAgent -● AccessAdmin -● AccessAssistant -● IMS Configuration Utility -The TOE is software only and is available in download format only from the IBM website. The TOE -installation must include the Fix Packs specified in Table 1. -Name -Type -Component -8.2.0-ISS-SAMESSO-AA-FP0022 -Fix Pack -AccessAgent -8.2.0-ISS-SAMESSO-IMS-IF0004 -Interim Fix -IMS Server -Table 1: Required Fix Packs -The TOE guidance is available online through the Tivoli Software Information Center, except for the -Common Criteria Guide which is available through the software download website. The relevant -guidance documents for the secure operation of the TOE are: -● IBM Security Access Manager for Enterprise Single Sign-On Administrator Guide -● IBM Security Access Manager for Enterprise Single Sign-On User Guide -● IBM Security Access Manager for Enterprise Single Sign-On Quick Start Guide -● IBM Security Access Manager for Enterprise Single Sign-On Common Criteria Guide -Section 1.4.1 lists the Operational Environment software products required by the TOE. -Page 13 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 1.5.3.2 Logical -Due to the nature of the TOE storing, providing, and operating on user credentials for other -applications, the TOE provides a number of security functions. Each security functional complex is -identified and described below: -● Audit - The TOE has the ability to audit the user actions performed by all roles and to store -the records in an audit trail using an external database. The Administrator role has the -ability to review the audit trail using the AccessAdmin component or by using the provided -database views. -● Identification and authentication - The TOE performs the identification and authentication -of all users, regardless of their role, before it allows the user to perform any other actions. -● User credential protection - The TOE stores the user's credentials for third-party applications -in the user's personal Wallet. A Wallet contains the user's arbitrary credentials which are -treated as opaque user data by the TOE. By using encryption mechanisms in the Operational -Environment, the TOE ensures the following: -❍ Only owners have access to credential data. -❍ The Administrator role can reset credential access data and restore use to a Wallet. -❍ A third-party application is given only the credentials which are intended for this -application and stored in the user's Wallet, preventing applications to "impersonate" -as a different application to illicitly obtain credentials. -● Security Management - Role-based access control is used to protect access to operations -in the AccessAdmin and AccessAssistant applications. -All cryptographic operations are performed by the Operational Environment. -1.5.3.3 Evaluated configuration -The following configuration specifics apply to the evaluated configuration of the TOE: -● The use of personal secrets must be disabled. -● Only the AccessAgent plugins provided with the TOE are allowed. -● Only the ISAM E-SSO Password authentication factor is allowed. -● Second factor authentication is disallowed. -● Self-service policies: -❍ Self-service password reset must be disabled. -❍ Self-service authorization code issuance must be disabled. -❍ Self-service registration and bypass of 2nd factor must be disabled. -❍ Self-service registering of additional secrets during sign-up must be disabled. -● The IMS Server's master secret must be protected to only allow the Administrator role -access to it. -● One-Time Passwords (OTPs) must be disabled. -● Mobile ActiveCode (MAC) must be disabled. -● Roaming Desktops (i.e., the use of Microsoft Windows Terminal Server and Citrix -Presentation Server) must be disabled. -● RADIUS authentication must be disabled. -● Windows Fast User Switching must be disabled on Windows 7 systems running AccessAgent. -● Private Desktop must be disabled on Windows XP systems running AccessAgent. -Page 14 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - ● Single sign-on to AccessAdmin when using Microsoft Internet Explorer must be disabled. -● The IMS Server/application must be the only application running in the WebSphere -Application Server (WAS). -● The TOE's password synchronization option with Active Directory affects the security of -the TOE. Specifically, enabling password synchronization with Active Directory will disable -the TOE's ability to enforce password quality requirements. -1.5.4 Security policy model -The security policy for the TOE is defined by the security functional requirements in chapter 6. The -following is a list of the subjects and objects participating in the policy. -Subjects: -● Users -Objects: -● Wallets -● Target applications -TSF data: -● AccessProfiles -● System policies, machine policies, and user policies -● User accounts, including the security attributes defined by FIA_ATD.1 -● Audit records -User data: -● User credential data stored within Wallets. -Page 15 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 2 CC Conformance Claim -This Security Target is CC Part 2 conformant and CC Part 3 conformant, with a claimed Evaluation -Assurance Level of EAL3, augmented by ALC_FLR.1. -This Security Target does not claim conformance to any Protection Profile. -Common Criteria [CC] version 3.1 revision 3 is the basis for this conformance claim. -Page 16 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 3 Security Problem Definition -3.1 Threat Environment -This section describes the threat model for the TOE and identifies the individual threats that are -assumed to exist in the TOE environment. -The assets to be protected by the TOE are the following: -● The IMS Server stores all its data within a relational database. The IMS Server's database -contains essentially these classes of data: -❍ System data - AccessProfiles, system policies, machine policies, user policies, and -other system configuration data -❍ User data - credentials -❍ Audit logs - user activities, administrative activities, SOAP event logs -● Additionally, the AccessAgent caches a subset of system and user data, so that it can -continue to function even when disconnected with the IMS Server. The AccessAgent caches -these data (in encrypted files) on workstations: -❍ System/machine data - AccessProfiles, system policies, machine policies, and user -policies -❍ User data - application credentials -❍ Audit logs - accessing of Wallet, using credentials out of the Wallet to provide to -an application based on the AccessProfiles -The threat agents having an interest in manipulating the data model can be categorized as either: -● Unauthorized individuals ("attackers") which are unknown to the TOE and its runtime -environment -● Authorized users of the TOE who try to manipulate data that they are not authorized to -access -Threat agents originate from a well managed user community within an organizations internal -network. Hence, only inadvertent or casual attempts to breach system security are expected from -this community. -TOE administrators, including administrators of the TOE environment, are assumed to be trustworthy, -trained and to follow the instructions provided to them with respect to the secure configuration -and operation of the systems under their responsibility. Hence, only inadvertent attempts to -manipulate the safe operation of the TOE are expected from this community. -3.1.1 Threats countered by the TOE -T.Manage -A threat agent gains access to the management facilities of the TOE allowing the modification -of the security-relevant configuration of the TOE. -T.UserCredentials -A threat agent gains access to user credentials stored for a user by the TOE. -Page 17 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 3.2 Assumptions -3.2.1 Environment of use of the TOE -3.2.1.1 Physical -A.Physical -It is assumed that the Operational Environment provides the TOE with appropriate physical -security, commensurate with the value of the IT assets protected by the TOE. -3.2.1.2 Personnel -A.AuthUser -Authorized users are expected to act in a cooperating manner in a benign environment. -Users are sufficiently trained and trusted to accomplish some task or group of tasks within -the secure Operational Environment by exercising complete control over their user data. -A.Manage -The TOE security functionality as well as the TOE's underlying systems and of the systems -in the TOE's Operational Environment that are involved in safeguarding TSF data or providing -functionality that the TOE depends on is managed by one or more competent individuals. -The system administrative personnel are not careless, willfully negligent, or hostile, and will -follow and abide by the instructions provided by the guidance documentation. -3.2.1.3 Logical -A.CryptoOps -The cryptographic operations performed by the Operational Environment are performed -according to the specified algorithm standards and the random number generation provides -sufficient randomness and entropy for key generation. -A.Remote -Threat agents are unable to violate the integrity, authenticity, and confidentiality of data -exchanged between the components of the TOE distributed in the deployment infrastructure. -A.Repositories -Threat agents are unable to gain access to TSF data or user data stored in the Operational -Environment, thus bypassing the TSF. -A.Runtime -The machines providing the runtime environment for the IMS Server are assumed to be -used solely for this purpose and not to run other application software except as required -for the support of the TOE and for the management and maintenance of the underlying -system and hardware. Especially, it is assumed that the underlying systems are configured -in a way that prevents unauthorized access to security functions provided by or protected -by the runtime environment either locally or via any network based connections. -Page 18 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - A.System -Threat agents are unable to circumvent the TSF by penetrating or manipulating the runtime -environment of the TOE and gain access to TSF or user data. -3.3 Organizational Security Policies -P.Accountability -Administrators and users are to be held accountable for security-relevant actions with the -TOE. -P.PasswordQuality -The quality of the ISAM E-SSO Password protecting the Common Symmetric Key (CSK) must -possess the strength to prevent credential guessing from threat agents. -P.User -Any user is trusted to perform the actions for which they have been authorized to perform. -Authorized users possess the necessary authorization to perform at least one operation on -the information managed by the TOE. -Page 19 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 4 Security Objectives -4.1 Objectives for the TOE -O.AccessProfiles -The TOE must only releases a subset of the credential information stored in a user's Wallet -to the target application the user intends to identify and authenticate to based on -AccessProfiles. -O.Audit -The TOE shall offer an audit mechanism that can be used to hold users of each role -accountable for security-relevant actions performed with the TSF. Security-relevant actions -audited by the audit mechanism shall include password changes and the accessing of Wallets. -Each audit record generated by the audit mechanism shall contain the time and date that -the event occurred. The TOE shall provide a mechanism for authorized users to review the -generated audit records. -O.Authentication -The TOE must ensure that only authorized users gain access to the TOE and its resources. -O.Manage -The TSF must provide all the functions and facilities necessary to support the authorized -users that are responsible for the management of TOE security mechanisms and must ensure -that only authorized users are able to access such functionality. -O.Role -The TOE must assign a role to each user after successful identification and authentication -to the management facility. This role limits the management actions the user is allowed to -perform. -O.PasswordQuality -When in GINA mode with Active Directory password synchronization disabled, the TOE must -ensure that the quality of the ISAM E-SSO Password protecting the Common Symmetric Key -(CSK) must possess the strength to prevent credential guessing from threat agents. -O.WalletAccess -The TOE must ensure that users can only access the contents of the Wallet assigned to -them. -4.2 Objectives for the Operational Environment -OE.CryptoOps -The cryptographic operations performed by the Operational Environment shall perform -according to the specified algorithm standards and the random number generation shall -provide sufficient randomness and entropy for key generation. -Page 20 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - OE.InfoProtect -Those responsible for the TOE must be competent individuals, not careless, willfully negligent, -or hostile. They must follow and abide by the instructions provided by the guidance -documentation. They must establish and implement procedures to ensure that information -is protected in an appropriate manner. In particular: -● All network communication channels and peripheral link must be approved for the -transmittal of the most sensitive data held by the system. Such links are assumed -to be adequately protected against threats to the authenticity, confidentiality and -integrity of the data transmitted. -● All repositories holding TSF data and user data stored in the Operational Environment -are access protected to restrict access to the TSF only. -OE.PasswordQuality -When either in GINA mode with Active Directory password synchronization enabled or when -in GINA-less mode, the runtime environment must ensure that the quality of the ISAM E-SSO -Password protecting the Common Symmetric Key (CSK) must possess the strength to prevent -credential guessing from threat agents. -OE.Physical -Those responsible for the TOE must ensure that those parts of the TOE critical to security -policy are protected from physical attack which might compromise IT security objectives. -The protection must commensurate with the value of the IT assets protected by the TOE. -OE.Runtime -The runtime environment used for all components of the TOE must be properly administered -and protected from interference by unauthorized entities. This includes the requirement -that the system(s) hosting components of the IMS Server are restricted to be used for this -purpose only. -OE.TimeSource -The runtime environment shall provide a reliable time source for the TOE's use. -OE.Users -The TOE users shall act in a cooperating manner in a benign environment. The TOE users -shall be trained and trusted to accomplish some task or group of tasks within the secure -Operational Environment by exercising complete control over their user data. -4.3 Security Objectives Rationale -4.3.1 Security objectives coverage -The following table provides a mapping of TOE objectives to threats and policies, showing that each -objective counters or enforces at least one threat or policy, respectively. -Page 21 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Threats / OSPs -Objective -T.UserCredentials -O.AccessProfiles -P.Accountability -O.Audit -T.Manage -O.Authentication -T.Manage -O.Manage -T.Manage -P.User -O.Role -P.PasswordQuality -O.PasswordQuality -T.UserCredentials -O.WalletAccess -Table 2: Mapping of security objectives to threats and policies -The following table provides a mapping of the objectives for the Operational Environment to -assumptions, threats and policies, showing that each objective holds, counters or enforces at least -one assumption, threat or policy, respectively. -Assumptions / Threats / OSPs -Objective -A.CryptoOps -OE.CryptoOps -A.Manage -A.Remote -A.Repositories -OE.InfoProtect -P.PasswordQuality -OE.PasswordQuality -A.Physical -OE.Physical -A.Runtime -A.System -OE.Runtime -P.Accountability -OE.TimeSource -A.AuthUser -OE.Users -Table 3: Mapping of security objectives for the Operational Environment to assumptions, -threats and policies -4.3.2 Security objectives sufficiency -The following rationale provides justification that the security objectives are suitable to counter -each individual threat and that each security objective tracing back to a threat, when achieved, -actually contributes to the removal, diminishing or mitigation of that threat: -Page 22 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Rationale for security objectives -Threat -The threat of unauthorized access to the management facilities of the -TOE is diminished by the objective O.Manage which specifies that specific -management facilities exist. -T.Manage -In addition, a role mechanism is enforced for users with O.Role which -supports the protection of the management facilities by limiting -management capabilities of users to their role. -For enforcing the role-based management mechanism, the TOE provides -an identification and authentication mechanism for users with -O.Authentication to allow the TOE to establish the user identity and the -associated role for that user. -The threat of unauthorized access to the credential data stored for a -user by the TOE is diminished by the objective O.AccessProfiles which -ensures that the TOE releases only the credentials required for a target -T.UserCredentials -application to the target application based on the AccessProfiles. An -AccessProfile restricts other credentials in the Wallet from being -decrypted by the Operational Environment and passed to a target -application by mapping Wallet credentials to target applications. In -addition, AccessProfiles provide methods to identify applications in order -to prevent a threat agent from using a spoof or rogue application to -obtain a user's credentials. -In addition, the TOE implements per-user Wallets which the user must -access using his ISAM E-SSO Password as specified with O.WalletAccess, -ensuring that only the owner of a Wallet can access the user's Wallet -holding the user's credentials. -Table 4: Sufficiency of objectives countering threats -The following rationale provides justification that the security objectives for the environment are -suitable to cover each individual assumption, that each security objective for the environment that -traces back to an assumption about the environment of use of the TOE, when achieved, actually -contributes to the environment achieving consistency with the assumption, and that if all security -objectives for the environment that trace back to an assumption are achieved, the intended usage -is supported: -Rationale for security objectives -Assumption -The assumption on physical protection of the TOE is achieved by the -environmental objective OE.Physical to provide such protection. -A.Physical -The assumption that authorized users are cooperative, trained, and -trusted is covered by the environmental objective OE.Users which -requires that the TOE users shall act in a cooperating manner in a benign -A.AuthUser -environment and the TOE users shall be trained and trusted to accomplish -some task or group of tasks within the secure Operational Environment -by exercising complete control over their user data. -Page 23 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Rationale for security objectives -Assumption -The assumptions that the management of the TOE and the underlying -environment is conducted by competent individuals who are not careless, -willfully negligent, or hostile, and will follow and abide by the instructions -A.Manage -provided by the guidance documentation are achieved by the -environmental objective OE.InfoProtect to ensure these properties of -administrators. -The assumptions that the cryptographic operations performed by the -Operational Environment are performed according to the specified -algorithm standards and the random number generation provides -A.CryptoOps -sufficient randomness and entropy for key generation are achieved by -the environmental objective OE.CryptoOps which states that the -cryptographic operations performed by the Operational Environment -shall perform according to the specified algorithm standards and the -random number generation shall provide sufficient randomness and -entropy for key generation. -The assumption that threat agents are unable to compromise the -exchange of data between the different distributed TOE components is -achieved by the environmental objective OE.InfoProtect which guarantees -A.Remote -that the environment protects these communication channels either by -physical means (such as dedicated network links to which routing from -outside networks is prohibited) or by logical means (such as the use of -cryptographically secured network channels). -The assumption that threat agents are unable to access the TOE -repositories holding TSF data and user data and bypass the TSF is -achieved by the environmental objective OE.InfoProtect which requires -an appropriate access restriction of those repositories to the TSF. -A.Repositories -The assumption on exclusive TOE use of the underlying machines for -the IMS Server and preventing unauthorized access to the TOE is -achieved by the environmental objective OE.Runtime to implement -corresponding measures for the server runtime environment. -A.Runtime -The assumption that threat agents are unable to manipulate the runtime -environment to circumvent the TSF is achieved by OE.Runtime which -specifies that this runtime environment must be properly administered -and protected from interference by unauthorized entities. -A.System -Table 5: Sufficiency of objectives holding assumptions -The following rationale provides justification that the security objectives are suitable to cover each -individual organizational security policy, that each security objective that traces back to an OSP, -when achieved, actually contributes to the implementation of the OSP, and that if all security -objectives that trace back to an OSP are achieved, the OSP is implemented: -Page 24 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Rationale for security objectives -OSP -The policy to provide accountability for the action of TOE administrators -and users is implemented by the objective O.Audit to provide an auditing -mechanism and supported by the environmental objective OE.TimeSource -to provide a reliable time source in the runtime environment. -P.Accountability -The policy that the ISAM E-SSO Password must possess the strength to -prevent credential guessing from threat agents is achieved by the -objectives O.PasswordQuality and OE.PasswordQuality which require -either the TOE or the runtime environment, respectively, to enforce the -password strength depending on the TOE's configuration. -P.PasswordQuality -The policy that users are trusted to perform the actions for which they -have been authorized to perform is achieved by the objective O.Role -which ensures that the TOE assigns a role to every user identifying and -authenticating with the TOE management facilities. -P.User -Table 6: Sufficiency of objectives enforcing Organizational Security Policies -Page 25 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 5 Extended Components Definition -This Security Target does not extend the security components provided by the Common Criteria. -Page 26 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 6 Security Requirements -6.1 TOE Security Functional Requirements -The following table shows the security functional requirements for the TOE, and the operations -performed on the components according to CC part 2: iteration (Iter.), refinement (Ref.), assignment -(Ass.) and selection (Sel.). -Operations -Source -Security functional requirement -Security -functional -group Sel. -Ass. -Ref. -Iter. -Yes -Yes -No -No -CC Part 2 -FAU_GEN.1 Audit data generation -FAU - Security -audit -No -No -No -No -CC Part 2 -FAU_GEN.2 User identity association -No -Yes -Yes -No -CC Part 2 -FAU_SAR.1 Audit review -No -No -No -No -CC Part 2 -FAU_SAR.2 Restricted audit review -Yes -No -No -No -CC Part 2 -FAU_STG.1 Protected audit trail storage -No -Yes -No -No -CC Part 2 -FDP_ACC.2 Subset access control -FDP - User data -protection -No -Yes -No -No -CC Part 2 -FDP_ACF.1 Security attribute based access control -No -Yes -No -No -CC Part 2 -FIA_ATD.1 User attribute definition -FIA - Identification -and -authentication No -Yes -No -No -CC Part 2 -FIA_SOS.1 Verification of secrets -No -No -No -No -CC Part 2 -FIA_UAU.2 User authentication before any action -No -No -No -No -CC Part 2 -FIA_UID.2 User identification before any action -No -Yes -No -No -CC Part 2 -FIA_USB.1 User-subject binding -Yes -Yes -No -No -CC Part 2 -FMT_MSA.1 Management of security attributes -FMT - Security -management -Yes -Yes -No -No -CC Part 2 -FMT_MSA.3 Static attribute initialisation -Yes -Yes -No -No -CC Part 2 -FMT_MTD.1 Management of TSF data -No -Yes -No -No -CC Part 2 -FMT_SMF.1 Specification of management functions -No -Yes -No -No -CC Part 2 -FMT_SMR.1 Security roles -Table 7: Security functional requirements for the TOE -Page 27 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 6.1.1 Security audit (FAU) -6.1.1.1 Audit data generation (FAU_GEN.1) -The TSF shall be able to generate an audit record of the following auditable events: -a) Start-up and shutdown of the audit functions; -b) All auditable events for the not specified level of audit; and -c) the following auditable events: -FAU_GEN.1.1 -● IMS Server: logins, password changes, role changes, policy changes -(for machine, system and user policies); -● AccessAgent: accessing of the Wallet, using credentials out of the -Wallet to provide to an application based on the AccessProfiles, -password changes. -Application note: The requirement to log startup and shutdown of the audit -functions is trivially satisfied as the audit system is running when the TOE runs -and cannot be turned off. -The TSF shall record within each audit record at least the following information: -a) Date and time of the event, type of event, subject identity (if applicable), and -the outcome (success or failure) of the event; and -b) For each audit event type, based on the auditable event definitions of the -functional components included in the PP/ST, no other information. -FAU_GEN.1.2 -6.1.1.2 User identity association (FAU_GEN.2) -For audit events resulting from actions of identified users, the TSF shall be able -to associate each auditable event with the identity of the user that caused the -event. -FAU_GEN.2.1 -6.1.1.3 Audit review (FAU_SAR.1) -The TSF shall provide users assigned to the Administrator role with the -capability to read all audit data from the audit records generated by the following -audit events: -FAU_SAR.1.1 -● IMS Server: logins, policy changes (for system and user policies only); -● AccessAgent: accessing of the Wallet, using credentials out of the Wallet to -provide to an application based on the AccessProfiles. -The TSF shall provide the audit records in a manner suitable for the user to -interpret the information. -FAU_SAR.1.2 -Application Note: The functionality of FAU_SAR.1 is provided by AccessAdmin. -6.1.1.4 Restricted audit review (FAU_SAR.2) -The TSF shall prohibit all users read access to the audit records, except those -users that have been granted explicit read-access. -FAU_SAR.2.1 -Page 28 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 6.1.1.5 Protected audit trail storage (FAU_STG.1) -The TSF shall protect the stored audit records in the audit trail from unauthorised -deletion. -FAU_STG.1.1 -The TSF shall be able to prevent unauthorised modifications to the stored audit -records in the audit trail. -FAU_STG.1.2 -6.1.2 User data protection (FDP) -6.1.2.1 Subset access control (FDP_ACC.2) -Wallet Access Control Policy -Definition -Short name -Type -A TOE user. -S_User -Subjects -A target application. -O_TargetApp -Objects -A user's Wallet. -O_Wallet -Decrypt the user's Common Symmetric Key (CSK) and the -user's target application credentials (using cryptographic -operations supplied by the Operational Environment). -Decrypt -Operations -Release the user's target application credentials for the -specified target application. -Release -A user's ISAM E-SSO Password for decrypting the user's -CSK. -AS_Password -Security -attributes of -subjects -The AccessProfile for the target application. -AO_AccessProfile -Security -attributes of -objects The user's CSK. -AO_CSK -If the user's CSK can be successfully decrypted by the -Operational Environment using a key derived from the -user's ISAM E-SSO Password, then the TOE provides the -user access to the user's Wallet; otherwise, access to the -user's Wallet is denied. -R_DecryptCSK -Rules -If the target application's AccessProfile key is found in the -user's Wallet, the user's credentials for only the target -application are decrypted by the Operational Environment -R_ReleaseCreds -using the user's CSK and released to the target application; -otherwise, no credentials are released to the target -application. -Table 8: Wallet Access Control Policy -The TSF shall enforce the Wallet Access Control Policy in Table 8 on subjects -and objects as defined in Table 8 and all operations among subjects and -objects covered by the SFP. -FDP_ACC.2.1 -Page 29 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - The TSF shall ensure that all operations between any subject controlled by the -TSF and any object controlled by the TSF are covered by an access control SFP. -FDP_ACC.2.2 -Application Note: An AccessProfile key is a key created from information specific to an interface -(e.g., a program's pathname and filename) that is used to reference the user's credentials for that -program in the user's Wallet. -Application Note: The Wallet Access Control Policy defined in FDP_ACC.2 is only enforced by the -AccessAgent. (The IMS Server does not enforce this policy.) -6.1.2.2 Security attribute based access control (FDP_ACF.1) -The TSF shall enforce the Wallet Access Control Policy in Table 8 to objects -based on the following: subjects, objects, and for each the security -attributes as defined in Table 8. -FDP_ACF.1.1 -The TSF shall enforce the following rules to determine if an operation among -controlled subjects and controlled objects is allowed: rules as defined in Table -8 performed in the following order: -FDP_ACF.1.2 -1. R_DecryptCSK; -2. R_ReleaseCreds. -The TSF shall explicitly authorize access of subjects to objects based on the -following additional rules: none. -FDP_ACF.1.3 -The TSF shall explicitly deny access of subjects to objects based on the following -additional rules: none. -FDP_ACF.1.4 -6.1.3 Identification and authentication (FIA) -6.1.3.1 User attribute definition (FIA_ATD.1) -The TSF shall maintain the following list of security attributes belonging to -individual users: -FIA_ATD.1.1 -● User identifier; -● Common Symmetric Key (CSK); -● Role. -6.1.3.2 Verification of secrets (FIA_SOS.1) -The TSF shall provide a mechanism to verify that secrets meet the following: -FIA_SOS.1.1 -● For each attempt to use the authentication mechanism, the -probability that a random attempt will succeed is less than one in -1,000,000; -● For multiple attempts to use the authentication mechanism during -a one minute period, the probability that a random attempt during -that minute will succeed is less than one in 100,000; and -● Any feedback given during an attempt to use the authentication -mechanism will not reduce the probability below the above metrics. -Page 30 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Application Note: The password strength policies are enforced by the TOE only when the TOE is -in GINA mode with Active Directory password synchronization disabled. The password strength -policies are not enforced when the TOE is in GINA-less mode. -6.1.3.3 User authentication before any action (FIA_UAU.2) -The TSF shall require each user to be successfully authenticated before allowing -any other TSF-mediated actions on behalf of that user. -FIA_UAU.2.1 -6.1.3.4 User identification before any action (FIA_UID.2) -The TSF shall require each user to be successfully identified before allowing any -other TSF-mediated actions on behalf of that user. -FIA_UID.2.1 -6.1.3.5 User-subject binding (FIA_USB.1) -The TSF shall associate the following user security attributes with subjects acting -on the behalf of that user: -FIA_USB.1.1 -● User identifier (which is associated with auditable events); -● Role. -The TSF shall enforce the following rules on the initial association of user security -attributes with subjects acting on the behalf of users: -FIA_USB.1.2 -● The IMS Server and all associated management interfaces: After -successful identification and authentication, the user identifier and -the role associated with the new session are set based on the -identifier and role specified for the user entry of the successfully -authenticated user. -● AccessAgent: After successful identification and authentication, the -user identifier associated with the new session is set based on the -identifier specified for the user entry of the successfully -authenticated user. -The TSF shall enforce the following rules governing changes to the user security -attributes associated with subjects acting on the behalf of users: none. -FIA_USB.1.3 -6.1.4 Security management (FMT) -6.1.4.1 Management of security attributes (FMT_MSA.1) -Wallet Access Control Policy management -Authorized users and roles -Security attributes -Operations -Administrator role -AccessProfile -Add, modify -Users who know the current ISAM E-SSO Password for the -user's CSK -ISAM E-SSO Password -Modify -Table 9: Wallet Access Control Policy management -Page 31 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - The TSF shall enforce the Wallet Access Control Policy in Table 8 to restrict -the ability to perform the operations as defined in Table 9 on the security -attributes as defined in Table 9 to the authorized users and roles as -defined in Table 9. -FMT_MSA.1.1 -Application Note: To add and modify AccessProfiles, the IMS Configuration Utility is used. To -modify ISAM E-SSO Passwords, AccessAgent is used. -6.1.4.2 Static attribute initialisation (FMT_MSA.3) -The TSF shall enforce the Wallet Access Control Policy in Table 8 to provide -restrictive default values for security attributes that are used to enforce the -SFP. -FMT_MSA.3.1 -The TSF shall allow nobody to specify alternative initial values to override the -default values when an object or information is created. -FMT_MSA.3.2 -6.1.4.3 Management of TSF data (FMT_MTD.1) -TSF data management -Authorized roles -TSF data -Operations -Administrator -Role user security attribute -Modify -Administrator -System policies and machine policies -Modify -Administrator and Help desk -System policies and machine policies -View -Administrator and Help desk -User policies -Modify, view -Table 10: TSF data management -The TSF shall restrict the ability to perform the operations in Table 10 on -the TSF data in Table 10 to the authorized roles in Table 10. -FMT_MTD.1.1 -Application Note: To perform the operations on the TSF data specified in Table 10, AccessAdmin -is used. -6.1.4.4 Specification of management functions (FMT_SMF.1) -The TSF shall be capable of performing the following management functions: -FMT_SMF.1.1 -● Assign roles to users (see FMT_MTD.1); -● Manage machine, system, and user policies (see FMT_MTD.1); -● View audit logs (see FAU_SAR.1). -6.1.4.5 Security roles (FMT_SMR.1) -The TSF shall maintain the roles -FMT_SMR.1.1 -● Administrator; -● Help desk; -● User. -Page 32 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - The TSF shall be able to associate users with roles. -FMT_SMR.1.2 -6.2 Security Functional Requirements Rationale -6.2.1 Security requirements coverage -The following table provides a mapping of SFR to the security objectives, showing that each security -functional requirement addresses at least one security objective. -Objectives -Security functional requirements -O.Audit -FAU_GEN.1 -O.Audit -FAU_GEN.2 -O.Audit -FAU_SAR.1 -O.Audit -FAU_SAR.2 -O.Audit -FAU_STG.1 -O.AccessProfiles, -O.WalletAccess -FDP_ACC.2 -O.AccessProfiles, -O.WalletAccess -FDP_ACF.1 -O.Authentication -FIA_ATD.1 -O.PasswordQuality -FIA_SOS.1 -O.Authentication -FIA_UAU.2 -O.Authentication -FIA_UID.2 -O.Audit, -O.Authentication -FIA_USB.1 -O.Manage -FMT_MSA.1 -O.Manage -FMT_MSA.3 -O.Manage -FMT_MTD.1 -O.Manage -FMT_SMF.1 -O.Role -FMT_SMR.1 -Table 11: Mapping of security functional requirements to security objectives -6.2.2 Security requirements sufficiency -The following rationale provides justification for each security objective for the TOE, showing that -the security functional requirements are suitable to meet and achieve the security objectives: -Page 33 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Rationale -Security objectives -The access control policy specified with FDP_ACC.2 and FDP_ACF.1 -ensures that only the intended credentials are released to the target -application. -O.AccessProfiles -The objective to provide means to audit security-relevant actions with -the TSF is met by requirements for audit record generation (FAU_GEN.1) -and association of audited events with the originating user ID -O.Audit -(FAU_GEN.2). Administrators have the ability to review audit data -(FAU_SAR.1). The audit data is stored in a protected environment -(FAU_STG.1) and the TOE ensures that it can only be read by authorized -users (FAU_SAR.2). Users are identified based on the established identity -during user-subject-binding (FIA_USB.1). -The TOE environment needs to provide the proper time for the generated -audit records, see OE.TimeSource. -Supportive management functions have been specified in FMT_SMF.1. -Identification and authentication is a prerequisite for the management -function and is defined with FIA_UAU.2 and FIA_UID.2. After the successful -identification and authentication, the TOE performs a user-subject-binding -as defined with FIA_USB.1. The security attributes maintained by the -TOE and used for the user-subject-binding are listed in FIA_ATD.1. -O.Authentication -The general management functions provided with the TOE are listed in -FMT_SMF.1 and detailed in FMT_MTD.1. In addition, the management of -user Wallets is defined with FMT_MSA.1 and FMT_MSA.3. -O.Manage -The definition of roles known to the TSF is specified with FMT_SMR.1. -O.Role -When in GINA mode with Active Directory password synchronization -disabled, the TOE ensures that the quality of the ISAM E-SSO Password -protecting the Common Symmetric Key (CSK), as specified by FIA_SOS.1, -must possess the strength to prevent credential guessing from threat -agents. -O.PasswordQuality -The access control policy specified with FDP_ACC.2 and FDP_ACF.1 -ensures that users can only access their Wallet. -O.WalletAccess -Table 12: Security objectives for the TOE rationale -6.2.3 Security requirements dependency analysis -The following table demonstrates the dependencies of SFRs modeled in CC Part 2 and how the SFRs -for the TOE resolve those dependencies: -Page 34 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Resolution -Dependencies -Security -Functional -Requirement -The TOE is application software and, -therefore, cannot provide reliable time -stamps. Reliable time stamps must be -provided by the Operational Environment. -See OE.TimeSource. -FPT_STM.1 -FAU_GEN.1 -FAU_GEN.1 -FAU_GEN.1 -FAU_GEN.2 -FIA_UID.2 -FIA_UID.1 -FAU_GEN.1 -FAU_GEN.1 -FAU_SAR.1 -FAU_SAR.1 -FAU_SAR.1 -FAU_SAR.2 -FAU_GEN.1 -FAU_GEN.1 -FAU_STG.1 -FDP_ACF.1 -FDP_ACF.1 -FDP_ACC.2 -FDP_ACC.2 -FDP_ACC.1 -FDP_ACF.1 -FMT_MSA.3 -FMT_MSA.3 -No dependencies. -FIA_ATD.1 -No dependencies. -FIA_SOS.1 -FIA_UID.2 -FIA_UID.1 -FIA_UAU.2 -No dependencies. -FIA_UID.2 -FIA_ATD.1 -FIA_ATD.1 -FIA_USB.1 -FDP_ACC.2 -[FDP_ACC.1 or FDP_IFC.1] -FMT_MSA.1 -FMT_SMR.1 -FMT_SMR.1 -FMT_SMF.1 -FMT_SMF.1 -FMT_MSA.1 -FMT_MSA.1 -FMT_MSA.3 -FMT_SMR.1 -FMT_SMR.1 -FMT_SMR.1 -FMT_SMR.1 -FMT_MTD.1 -FMT_SMF.1 -FMT_SMF.1 -No dependencies. -FMT_SMF.1 -FIA_UID.2 -FIA_UID.1 -FMT_SMR.1 -Table 13: TOE SFR dependency analysis -Page 35 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 6.3 Security Assurance Requirements -The security assurance requirements for the TOE are the Evaluation Assurance Level 3 components -as specified in [CC] part 3, augmented by ALC_FLR.1. -The following table shows the Security assurance requirements, and the operations performed on -the components according to CC part 3: iteration (Iter.), refinement (Ref.), assignment (Ass.) and -selection (Sel.). -Operations -Source -Security assurance requirement -Security -assurance class -Sel. -Ass. -Ref. -Iter. -No -No -No -No -CC Part 3 -ADV_ARC.1 Security architecture description -ADV Development -No -No -No -No -CC Part 3 -ADV_FSP.3 Functional specification with complete -summary -No -No -No -No -CC Part 3 -ADV_TDS.2 Architectural design -No -No -No -No -CC Part 3 -AGD_OPE.1 Operational user guidance -AGD Guidance -documents -No -No -No -No -CC Part 3 -AGD_PRE.1 Preparative procedures -No -No -No -No -CC Part 3 -ALC_CMC.3 Authorisation controls -ALC Life-cycle -support -No -No -No -No -CC Part 3 -ALC_CMS.3 Implementation representation CM -coverage -No -No -No -No -CC Part 3 -ALC_DEL.1 Delivery procedures -No -No -No -No -CC Part 3 -ALC_DVS.1 Identification of security measures -No -No -No -No -CC Part 3 -ALC_FLR.1 Basic flaw remediation -No -No -No -No -CC Part 3 -ALC_LCD.1 Developer defined life-cycle model -No -No -No -No -CC Part 3 -ASE_INT.1 ST introduction -ASE Security -Target evaluation -No -No -No -No -CC Part 3 -ASE_CCL.1 Conformance claims -No -No -No -No -CC Part 3 -ASE_SPD.1 Security problem definition -No -No -No -No -CC Part 3 -ASE_OBJ.2 Security objectives -No -No -No -No -CC Part 3 -ASE_ECD.1 Extended components definition -No -No -No -No -CC Part 3 -ASE_REQ.2 Derived security requirements -No -No -No -No -CC Part 3 -ASE_TSS.1 TOE summary specification -No -No -No -No -CC Part 3 -ATE_COV.2 Analysis of coverage -ATE Tests -No -No -No -No -CC Part 3 -ATE_DPT.1 Testing: basic design -No -No -No -No -CC Part 3 -ATE_FUN.1 Functional testing -No -No -No -No -CC Part 3 -ATE_IND.2 Independent testing - sample -Page 36 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - Operations -Source -Security assurance requirement -Security -assurance class -Sel. -Ass. -Ref. -Iter. -No -No -No -No -CC Part 3 -AVA_VAN.2 Vulnerability analysis -AVA Vulnerability -assessment -Table 14: Security assurance requirements -6.4 Security Assurance Requirements Rationale -The evaluation assurance level has been chosen to match a Basic attack potential commensurate -with the threat environment that is experienced by typical consumers of the TOE. In addition, the -evaluation assurance level has been augmented with ALC_FLR.1 commensurate with the augmented -flaw remediation capabilities offered by the developer beyond those required by the evaluation -assurance level. -Page 37 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 7 TOE Summary Specification -7.1 TOE Security Functionality -The following section explains how the security functions are implemented. The different TOE -security functions cover the various SFR classes. -The primary security features of the TOE are: -● Audit -● Identification and Authentication -● User Data Protection -● Security Management -Of the policies referred to in the sections below, only the password strength policies are evaluated -by this evaluation. -7.1.1 Audit -Various components of the product generate audit events which are stored in the IMS Server -database. -All user application access logs are collated into the IMS Server's audit log database. Each log record -contains info related to time and location from which a user accesses a certain application. Using -AccessAdmin, the Administrator role can generate reports to review the logs contained in the -database. Several predefined audit reports come standard with the TOE. Only users with the -Administrator role are allowed access to the audit records via the TOE, preventing both unauthorized -access to and unauthorized deletion of the stored audit records. -The TOE provides audit records for the following types of events besides the start-up and shutdown -of the audit functions: -● IMS Server: -❍ logins -❍ password changes -❍ role changes -❍ policy changes (for machine, system and user policies) -● AccessAgent: -❍ accessing of the Wallet -❍ using credentials out of the Wallet to provide to an application based on the -AccessProfiles -❍ password changes -The audit records include the date and time of the event, the type of event, the subject identity -and the event outcome. The audit record time stamps are obtained from a reliable time source in -the Operational Environment. -The Administrator role can view and search a subset of the audit records through the TOE using -AccessAdmin. The subset that can be viewed and searched are: -● IMS Server: -❍ logins -❍ policy changes (for system and user policies only) -Page 38 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - ● AccessAgent: -❍ accessing of the Wallet -❍ using credentials out of the Wallet to provide to an application based on the -AccessProfiles -This section maps to the following SFR(s): -● FAU_GEN.1 -● FAU_GEN.2 -● FAU_SAR.1 -● FAU_SAR.2 -● FAU_STG.1 -7.1.2 Identification and authentication (I&A) -The TOE supports an identification mechanism and an authentication mechanism. This section -describes the supported mechanism. -The TOE maintains its own user repository, and performs user authentication against various forms -of authentication credentials stored in this repository (stored in the IMS Server database). The -user's ISAM E-SSO Password is created when the account is first created (when the user first sign's -up). -The user's Wallet, which contains his authentication data, is stored centrally in the IMS Server -database. Additionally, the authentication data is cached onto the user's workstation disk whenever -the user caches his Wallet to a machine. This allows the AccessAgent to be able to authenticate -users even when the machine cannot connect to the IMS Server. -An enterprise can ensure that its users use strong passwords to log on to the TOE by enforcing -ISAM E-SSO Password strength policies. -7.1.2.1 AccessAgent -AccessAgent is a Windows application. It authenticates users based on their user identifier and -password. A unique-per-user, 128 bit Common Symmetric Key (CSK) is generated by the Operational -Environment at the request the AccessAgent for the user when the user initially sign's up through -the AccessAgent. This CSK is associated with the user's account and is maintained by the TOE in -the Cryptobox that contains the user's Wallet. The TOE passes the user's password along with the -user's encrypted Common Symmetric Key (CSK) from the Cryptobox to the cryptographic operations -in the Operational Environment to obtain the user's CSK. The user is considered authenticated by -the TOE if the user's CSK is successfully obtained. (Authentication with one-time passwords (OTP) -is disabled in the evaluated configuration.) -If the AccessAgent has a network connection to the IMS Server, it will authenticate a user against -the user's credentials stored in the IMS Server, by passing along the authentication credentials -over HTTPS to the IMS Server. However, if the AccessAgent is offline to the IMS Server, it will then -authenticate the user's presented credentials against cached authentication data stored on the -disk in the user's Cryptobox. -For AccessAgents installed with the GINA option enabled (i.e., in GINA mode), a user will log on to -the AccessAgent GINA first, whereupon the AccessAgent will auto-logon the user into Windows -using the user's Windows account. -Page 39 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - For AccessAgents installed with the GINA option disabled (i.e., in GINA-less mode), the user will log -on to Windows manually first, and then the AccessAgent will auto-logon the user into his Wallet. -Authentication of users by the AccessAgent is carried out in accordance to Authentication Policies -defined by the Administrator role at the IMS Server and sync-ed to various AccessAgents. -AccessAgent allows each user to change his own ISAM E-SSO Password. The TOE's password strength -policies are enforced only when the AccessAgent is in GINA mode with Active Directory password -synchronization disabled. When in GINA-less mode or when Active Directory password synchronization -is enabled, the Active Directory's password strength policy is enforced by Active Directory, not the -TOE. -This section and its subsections map to the following SFR(s): -● FIA_ATD.1 -● FIA_SOS.1 -● FIA_UAU.2 -● FIA_UID.2 -● FIA_USB.1 -7.1.2.2 AccessAssistant -Users perform form-based logon to AccessAssistant using their username and ISAM E-SSO Password. -The AccessAssistant authenticates a user by making SOAP-based logon calls, with the user-provided -credentials, to the IMS Server, where the credentials are verified against the authentication data -stored in the IMS Server database. -This section and its subsections map to the following SFR(s): -● FIA_ATD.1 -● FIA_UAU.2 -● FIA_UID.2 -● FIA_USB.1 -7.1.2.3 AccessAdmin -Only users who are assigned Administrator or Help desk roles can log on to AccessAdmin. Users -authenticate to AccessAdmin using the following method: -● Form-based logon (over HTTPS) using a username and ISAM E-SSO Password. -The authentication and access control is implemented by the AccessAdmin/IMS application, which -will lookup the user's authentication data as well as assigned roles stored in the IMS Server database. -This section and its subsections map to the following SFR(s): -● FIA_ATD.1 -● FIA_UAU.2 -● FIA_UID.2 -● FIA_USB.1 -7.1.2.4 IMS Configuration Utility -The IMS Configuration Utility is a web-based utility for editing the IMS Server's configuration. It uses -authentication and access control provided by the Operational Environment. -Page 40 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 7.1.3 User data protection -The TOE supports a user data protection mechanism. This section describes the supported -mechanism. -The TOE stores each user's credential data in a Wallet; one Wallet per-user. A Wallet provides -confidentiality and integrity protection of the user credential data through the use of cryptographic -operations. All cryptographic operations are performed by the Operational Environment. -When a user sign's up via the TOE, the TOE creates a Wallet for the user and has the Operational -Environment generate a 128 bit cryptographic key called the Common Symmetric Key (CSK). -The CSK is unique for each user and is used for encrypting the user's credential data stored in the -user's Wallet. The CSK, in turn, is encrypted with a key derived from the user's ISAM E-SSO Password -using AES 128 bit Cipher Block Chaining (CBC) mode. To decrypt items in the user's Wallet, the -user supplies a valid ISAM E-SSO Password. The TOE provides the user's ISAM E-SSO Password and -the user's encrypted CSK as input to cryptographic operations in the Operational Environment to -obtain the CSK. The TOE then passes this CSK and an encrypted Wallet Credential from the user's -Wallet as input to cryptographic operations in the Operational Environment to obtain a decrypted -Wallet credential. For a user to change/modify the password of a Wallet, the user must know the -current password for the TOE initiated decryption operations to succeed and to obtain the CSK. The -AccessAgent allows each user to change his own ISAM E-SSO Password. -Both the Wallet and the password-encrypted CSK are stored in a secure data file on the AccessAgent -called a Cryptobox; one Cryptobox per-user. The information in the Cryptobox is sent to the IMS -Server for storage. -Since the CSK is required to access the credentials in the user's Wallet and the CSK is encrypted -with the user's ISAM E-SSO Password, the TOE does not store user ISAM E-SSO Paswords anywhere -in the system. Instead, the TOE requires users to supply their ISAM E-SSO Passwords each time -they log in. -The IMS Server stores only the encrypted forms of the user's credential data and CSK. By default, -the access controls on the IMS Server database are configured such that only an IMS Server-specific -database account, and the database administrators are allowed to access the data. -Each Cryptobox file and its containing folder are protected by Windows ACLs, so normal Windows -users will not be able to read and/or copy the files. -The AccessAgent's Single Sign-On function uses AccessProfiles to determine how to identify the -target requesting the credentials, which credentials in the user's Wallet match the target, and how -to provide the user's credentials to the target. If the target is an application, the AccessProfile -specifies the executable path and file name, and the TOE uses these values to create a key, called -an AccessProfile key, which is used to access the credentials in the user's Wallet. If the target uses -GUI widgets, the AccessProfile specifies the GUI widgets, and the TOE uses the GUI widget values -to create a key which is used to access the credentials in the user's Wallet. In addition, AccessProfiles -can optionally specify workflow automation for use where complicated workflow is required. -AccessProfiles are created and modified outside of the TOE using AccessStudio which is part of the -Operational Environment. The IMS Configuration Utility is used to add new AccessProfiles to the -IMS Server and to modify existing AccessProfiles that are used by the IMS Server. -Only the AccessAgent enforces the Wallet Access Control Policy defined by FDP_ACC.2 and -FDP_ACF.1. The IMS Server and other TOE components provide only a supporting role for this policy. -This section maps to the following SFR(s): -● FDP_ACC.2 -Page 41 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - ● FDP_ACF.1 -● FMT_MSA.1 -● FMT_MSA.3 -7.1.4 Security management -The TOE supports security function management mechanisms. This section describes the supported -mechanisms. -Role-based access control is used to protect access to operations in the AccessAdmin and -AccessAssistant applications. -Users are classified into three roles: -● Administrator -● Help desk -● User -The Administrator role is the most powerful of all the roles. The Help desk role is more powerful -than the User role, but less powerful than the Administrator role. The User role is the least powerful -of the roles and is intended for ordinary users. -A new user is granted the User role by default when they first sign-up. -The initial Administrator user account is created during the IMS Server's configuration, using the -IMS Web Configurator. Subsequently, an Administrator user can promote (i.e., modify the role of) -any user to Administrator or Help desk role through the AccessAdmin interface. -Only users with Administrator role will have full access to the AccessAdmin application. For example, -only Administrative users can modify machine policies and system policies. They can also view -machine policies and system policies, and view and modify user policies. -The Help desk role provides some of the capabilities of the Administrator role. The Help desk role -can view and modify user policies and view system policies and machine policies. -The TOE roles are stored in the IMS Server DB tables and managed by the AccessAdmin/IMS -application. Access control (based on these roles) to the IMS Server's various services is enforced -by the IMS Server. -The TOE contains several types of access policies that are used as configuration data by the TOE. -These access policies are grouped into the following major categories: -● Machine policies -● System policies -● User policies -Machine policies are policies that affect a specific machine or computer. Policies in this category -include the audit logging policies, desktop inactivity policies, and some of the Wallet-related policies -such as limiting the number of Wallets allowed on a machine and only allowing the Wallet to be -used on the machine where it was created. -System policies are policies that are applicable to all users and machines. Policies in this category -include auditing policies, password strength policies, and some of the Wallet-related policies. -User policies are policies that affect a specific user. Policies in this category include the Log on/Log -off policies and some of the Wallet-related policies such as the option for displaying of application -passwords in AccessAgent. -Page 42 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - This section maps to the following SFR(s): -● FMT_MTD.1 -● FMT_SMF.1 -● FMT_SMR.1 -Page 43 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - 8 Abbreviations, Terminology and References -8.1 Abbreviations -AA -AccessAgent -AD -Active Directory -AES -Advanced Encryption Standard -API -Application Programming Interface -CBC -Cipher Block Chaining -CSK -Common Symmetric Key -E-SSO -Enterprise Single Sign-On -GINA -Graphical Identification and Authentication -GSKit -IBM Global Security Toolkit -GUI -Graphical User Interface -HTTPS -Hypertext Transfer Protocol Secure -IMS -Integrated Management System -ISAM -IBM Security Access Manager -LDAP -Lightweight Directory Access Protocol -MAC -Mobile ActiveCode -OTP -One-Time Password -RADIUS -Remote Authentication Dial In User Service -RFID -Radio Frequency Identification -SFP -Security Function Policy -Page 44 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - SFR -Security Functional Requirement -SOAP -Originally defined as Simple Object Access Protocol -SPI -Service Provider Interface -SSL -Secure Sockets Layer -SSO -Single Sign-On -ST -Security Target -TCP/IP -Transmission Control Protocol / Internet Protocol -TLS -Transport Layer Security -TOE -Target of Evaluation -TSF -TOE Security Functionality -UI -User Interface -USB -Universal Serial Bus -WAS -WebSphere Application Server -XML -Extensible Markup Language -8.2 Terminology -This section contains definitions of technical terms that are used with a meaning specific to this -document. Terms defined in the [CC] are not reiterated here, unless stated otherwise. -AccessAgent -Client software that captures the user's credentials and acts on the user's behalf for single -sign-on and sign-off. -Authentication Factors -Different methods for authenticating to the product, such as USB keys, biometrics, proximity -cards, and passwords. See section 1.5.3.3 for the authentication factors supported in the -evaluated configuration. -GINA-less mode -Defines the mode where the IBM Security Access Manager for Enterprise Single Sign-On (ISAM -E-SSO) GINA is not installed on the operating system. -Page 45 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - GINA mode -Defines the mode where the IBM Security Access Manager for Enterprise Single Sign-On (ISAM -E-SSO) GINA is installed and used by the operating system. -GUI Widget -See Target Widget. -IMS Server -Provides centralized management of all users and policies. All policies are defined centrally and -enforced through AccessAgent. The IMS Server also provides comprehensive back-up of -credentials, loss management, audit, and compliance reporting. -Target Widget -A GUI widget belonging to an application monitored by the AccessAgent. The widget is monitored -by the TOE and filled in with information from the user's Wallet when applicable. For example, -a monitored application maintains a GUI widget referenced with "password" used to provide a -password to log into the application. The AccessAgent monitors the application for that -"password" widget in particular. If this widget is displayed, the AccessAgent detects the widget -and fills in the password information for the monitored application from the user's Wallet. -User -Humans or machines interacting with the TOE via the provided user and programmatic interfaces. -The term user in this document includes administrators of the TOE unless a specific distinction -is made in the text. -Wallet -A personal, encrypted repository of user credentials. The Wallet roams to the point of access -and stores the user's personal identity profiles, including log-in credentials, certificates, -encryption keys, and user policies. -8.3 References -Common Criteria for Information Technology Security Evaluation -CC -3.1R3 -Version -July 2009 -Date -http://www.commoncriteriaportal.org/files/ccfiles/CC -PART1V3.1R3.pdf -Location -http://www.commoncriteriaportal.org/files/ccfiles/CC -PART2V3.1R3.pdf -Location -http://www.commoncriteriaportal.org/files/ccfiles/CC -PART3V3.1R3.pdf -Location -Page 46 of 46 -Version: 1.19 -Copyright © 2009 - 2014 by atsec information security and IBM -Last update: 2014-03-05 -International Business Machines, Corporation -IBM Security Access Manager for Enterprise Single -Sign-On Version 8.2 with IMS Server Interim Fix 4 and -AccessAgent Fix Pack 22 Security Target - \ No newline at end of file diff --git a/tests/data/cc/analysis/certs/targets/txt/ed91ff3e658457fd.txt b/tests/data/cc/analysis/certs/targets/txt/ed91ff3e658457fd.txt new file mode 100644 index 00000000..fc0c022a --- /dev/null +++ b/tests/data/cc/analysis/certs/targets/txt/ed91ff3e658457fd.txt @@ -0,0 +1,2168 @@ +IBM Security Access Manager for Enterprise +Single Sign-On Version 8.2 with IMS Server +Interim Fix 4 and AccessAgent Fix Pack 22 +Security Target +1.19 +Version: +Released +Status: +2014-03-05 +Last Update: + Trademarks +IBM and the IBM logo are trademarks or registered trademarks of International Business Machines +Corporation in the United States, other countries, or both. +The following terms are trademarks of International Business Machines Corporation in the United +States, other countries, or both: +● DB2® +● WebSphere® +The following terms are trademarks of Oracle Corporation: +● Java® +● Oracle® +The following terms are trademarks of Microsoft Corporation: +● Active Directory® +● SQL Server® +● Windows® +● Windows Server® +Legal Notice +This document is provided AS IS with no express or implied warranties. Use the information in this +document at your own risk. +This document may be reproduced or distributed in any form without prior permission provided the +copyright notice is retained on all copies. Modified versions of this document may be freely distributed +provided that they are clearly identified as such, and this copyright is included intact. +Revision History +Changes to Previous Revision +Author(s) +Date +Revision +Initial ST. +Scott Chapman +2014-03-05 +1.19 +Page 2 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Table of Contents +1 Introduction .................................................................................................... 7 +1.1 Security Target Identification ......................................................................................... 7 +1.2 TOE Identification .......................................................................................................... 7 +1.3 TOE Type ....................................................................................................................... 7 +1.4 TOE Overview ................................................................................................................ 7 +1.4.1 Required non-TOE software .................................................................................. 7 +1.4.2 Intended method of use ........................................................................................ 8 +1.4.3 Major security features ......................................................................................... 8 +1.5 TOE Description ............................................................................................................. 8 +1.5.1 Introduction ........................................................................................................... 8 +1.5.2 Architecture .......................................................................................................... 9 +1.5.2.1 Communications ........................................................................................... 9 +1.5.2.2 The IMS Server ........................................................................................... 10 +1.5.2.3 AccessAgent ............................................................................................... 11 +1.5.2.4 AccessAdmin .............................................................................................. 12 +1.5.2.5 AccessAssistant .......................................................................................... 12 +1.5.2.6 IMS Configuration Utility ............................................................................. 13 +1.5.3 TOE boundaries ................................................................................................... 13 +1.5.3.1 Physical ...................................................................................................... 13 +1.5.3.2 Logical ........................................................................................................ 14 +1.5.3.3 Evaluated configuration ............................................................................. 14 +1.5.4 Security policy model .......................................................................................... 15 +2 CC Conformance Claim ................................................................................... 16 +3 Security Problem Definition ............................................................................ 17 +3.1 Threat Environment ..................................................................................................... 17 +3.1.1 Threats countered by the TOE ............................................................................ 17 +3.2 Assumptions ................................................................................................................ 18 +3.2.1 Environment of use of the TOE ........................................................................... 18 +3.2.1.1 Physical ...................................................................................................... 18 +3.2.1.2 Personnel .................................................................................................... 18 +3.2.1.3 Logical ........................................................................................................ 18 +3.3 Organizational Security Policies ................................................................................... 19 +4 Security Objectives ........................................................................................ 20 +4.1 Objectives for the TOE ................................................................................................. 20 +4.2 Objectives for the Operational Environment ................................................................ 20 +4.3 Security Objectives Rationale ...................................................................................... 21 +4.3.1 Security objectives coverage .............................................................................. 21 +4.3.2 Security objectives sufficiency ............................................................................ 22 +5 Extended Components Definition .................................................................... 26 +6 Security Requirements ................................................................................... 27 +6.1 TOE Security Functional Requirements ........................................................................ 27 +Page 3 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 6.1.1 Security audit (FAU) ............................................................................................ 28 +6.1.1.1 Audit data generation (FAU_GEN.1) .......................................................... 28 +6.1.1.2 User identity association (FAU_GEN.2) ...................................................... 28 +6.1.1.3 Audit review (FAU_SAR.1) .......................................................................... 28 +6.1.1.4 Restricted audit review (FAU_SAR.2) ......................................................... 28 +6.1.1.5 Protected audit trail storage (FAU_STG.1) ................................................. 29 +6.1.2 User data protection (FDP) .................................................................................. 29 +6.1.2.1 Subset access control (FDP_ACC.2) ........................................................... 29 +6.1.2.2 Security attribute based access control (FDP_ACF.1) ................................ 30 +6.1.3 Identification and authentication (FIA) ................................................................ 30 +6.1.3.1 User attribute definition (FIA_ATD.1) ......................................................... 30 +6.1.3.2 Verification of secrets (FIA_SOS.1) ............................................................ 30 +6.1.3.3 User authentication before any action (FIA_UAU.2) ................................... 31 +6.1.3.4 User identification before any action (FIA_UID.2) ...................................... 31 +6.1.3.5 User-subject binding (FIA_USB.1) .............................................................. 31 +6.1.4 Security management (FMT) ............................................................................... 31 +6.1.4.1 Management of security attributes (FMT_MSA.1) ...................................... 31 +6.1.4.2 Static attribute initialisation (FMT_MSA.3) ................................................. 32 +6.1.4.3 Management of TSF data (FMT_MTD.1) ..................................................... 32 +6.1.4.4 Specification of management functions (FMT_SMF.1) ............................... 32 +6.1.4.5 Security roles (FMT_SMR.1) ....................................................................... 32 +6.2 Security Functional Requirements Rationale ............................................................... 33 +6.2.1 Security requirements coverage ......................................................................... 33 +6.2.2 Security requirements sufficiency ....................................................................... 33 +6.2.3 Security requirements dependency analysis ...................................................... 34 +6.3 Security Assurance Requirements ............................................................................... 36 +6.4 Security Assurance Requirements Rationale ............................................................... 37 +7 TOE Summary Specification ............................................................................ 38 +7.1 TOE Security Functionality ........................................................................................... 38 +7.1.1 Audit .................................................................................................................... 38 +7.1.2 Identification and authentication (I&A) ............................................................... 39 +7.1.2.1 AccessAgent ............................................................................................... 39 +7.1.2.2 AccessAssistant .......................................................................................... 40 +7.1.2.3 AccessAdmin .............................................................................................. 40 +7.1.2.4 IMS Configuration Utility ............................................................................. 40 +7.1.3 User data protection ........................................................................................... 41 +7.1.4 Security management ......................................................................................... 42 +8 Abbreviations, Terminology and References .................................................... 44 +8.1 Abbreviations ............................................................................................................... 44 +8.2 Terminology ................................................................................................................. 45 +8.3 References ................................................................................................................... 46 +Page 4 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + List of Tables +Table 1: Required Fix Packs .................................................................................................. 13 +Table 2: Mapping of security objectives to threats and policies ........................................... 22 +Table 3: Mapping of security objectives for the Operational Environment to assumptions, +threats and policies ........................................................................................................ 22 +Table 4: Sufficiency of objectives countering threats ........................................................... 23 +Table 5: Sufficiency of objectives holding assumptions ....................................................... 23 +Table 6: Sufficiency of objectives enforcing Organizational Security Policies ....................... 25 +Table 7: Security functional requirements for the TOE ......................................................... 27 +Table 8: Wallet Access Control Policy ................................................................................... 29 +Table 9: Wallet Access Control Policy management ............................................................. 31 +Table 10: TSF data management ......................................................................................... 32 +Table 11: Mapping of security functional requirements to security objectives ..................... 33 +Table 12: Security objectives for the TOE rationale ............................................................. 34 +Table 13: TOE SFR dependency analysis .............................................................................. 35 +Table 14: Security assurance requirements ......................................................................... 36 +Page 5 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + List of Figures +Figure 1: TOE Component Relationships ................................................................................ 9 +Figure 2: TOE Dataflow ......................................................................................................... 10 +Page 6 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 1 Introduction +1.1 Security Target Identification +IBM Security Access Manager for Enterprise Single Sign-On Version 8.2 with +IMS Server Interim Fix 4 and AccessAgent Fix Pack 22 Security Target +Title: +1.19 +Version: +Released +Status: +2014-03-05 +Date: +International Business Machines, Corporation +Sponsor: +International Business Machines, Corporation +Developer: +BSI +Certification Body: +BSI-DSZ-CC-0683 +Certification ID: +Security Access Manager, Enterprise Single Sign-On +Keywords: +1.2 TOE Identification +The TOE is IBM Security Access Manager for Enterprise Single Sign-On Version 8.2 with IMS Server +Interim Fix 4 and AccessAgent Fix Pack 22. +1.3 TOE Type +The TOE type is an enterprise single sign-on product for Microsoft Windows-based systems and +consists of software and guidance documentation. +1.4 TOE Overview +The Target of Evaluation (TOE) provides enterprises with single sign-on services, coupled with +strong authentication and comprehensive auditing capabilities. The TOE keeps track of each user's +application credentials (ID/password) in a credential Wallet, and helps users log onto the various +applications. This is achieved through a client-side software "agent" called the AccessAgent that, +in addition to automating application logons, provides application access audit logging. An important +characteristic of the TOE is that this agent emulates the logon actions of the user using the +application native logon interfaces – as such, it will work with applications as-is, without requiring +any applications to be re-programmed or re-configured. The TOE includes a central server called +the IMS (Integrated Management System) Server for storing user Wallets and for providing centralized +management of users and policies. +1.4.1 Required non-TOE software +The Operational Environment for the TOE consists of the following required software products: +● Microsoft Windows XP and Windows 7 for the AccessAgents (32-bit and 64-bit Windows) +● Microsoft Windows Server 2008 (32-bit/64-bit) for the IMS Server +● Microsoft Active Directory (AD) +● WebSphere Application Server (WAS) 7.0 (32-bit only) required by the IMS Server +● One of the following SQL-based databases required by the IMS Server: +❍ IBM DB2 +Page 7 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + ❍ Microsoft SQL Server +❍ Oracle Database +● Java Runtime Environment (IBM Java 6 for WAS 7.0) +● IBM Global Security Kit (GSKit) version 8.0.14.21 required by the AccessAgent. +1.4.2 Intended method of use +The TOE is intended to be used in a distributed Microsoft Windows environment for the automatic +authentication of users to applications. The TOE components use network security protocols (i.e., +SSL, TLS) to protect network data from disclosure and modification when communicating between +one another, so network eavesdropping attacks on TOE communication data is significantly +diminished. (The network security protocols and all cryptographic operations used by the protocols +including random number generation are provided by the Operational Environment.) +1.4.3 Major security features +The main security functions of the TOE are: +● Audit - Generation and review of audit records +● I&A - The identification and authentication of all users (regardless of their role) +● User data protection - Protection of user data stored within Wallets +● Security management - Role-based management of security behavior of the TOE +1.5 TOE Description +1.5.1 Introduction +The TOE is an enterprise single sign-on product for Microsoft Windows-based systems and consists +of software and guidance documentation. +The TOE automatically enters user credentials into credential-requesting applications on behalf of +the user once the user has successfully authenticated to the TOE. +For every user, the TOE maintains a set of application-to-user-credential mappings in a secure +Wallet. Each Wallet is encrypted with a Common Symmetric Key (CSK) which is uniquely generated +for each user. (The encryption operations and CSK key generation are performed by the Operational +Environment at the request of the TOE. The TOE controls the flow of the cryptographic operations +performed by the Operational Environment.) A more detailed description of Wallets and CSKs is +provided in section 7.1.3. +The TOE contains several types of access policies that are used as configuration data by the TOE. +These access policies are grouped into the following major categories: +● Machine policies - policies that affect a specific machine/computer (e.g., audit logging +policies, desktop inactivity policies, some Wallet policies). +● System policies - policies applicable to all users and machines (e.g., auditing policies, +password strength policies, some Wallet policies). +● User policies - policies that affect a specific user (e.g., Log on/Log off policies, some Wallet +policies). +Of the policies referred to above, only the password strength policies are evaluated by this evaluation. +Page 8 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + The TOE supports user role-based access control. Role-based access control is used to restrict user +access to certain TOE operations. The TOE implements the following user roles which are referred +to in the follow-on sections (for more detailed role descriptions, see section 7.1.4): +● Administrator +● Help desk +● User +1.5.2 Architecture +The TOE consists of multiple components executing in a distributed environment and communicating +using the network. Figure 1 depicts the different components forming the product. Each of the +green shaded components will be described in the subsequent sections. These green shaded +components together form the TOE. +Figure 1: TOE Component Relationships +1.5.2.1 Communications +The relevant communication relationships for the TOE are shown in figure 2. +Page 9 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Figure 2: TOE Dataflow +1.5.2.2 The IMS Server +The IMS (Integrated Management System) Server serves as the central repository and management +point for all system and user data consumed by the AccessAgents. The IMS Server performs the +following functions: +● Serves as a central repository and distribution point for AccessProfiles and other system +data. +● Serves as a central repository for all user data, including his credential Wallet and various +authentication and access policies. +● Provides an internal SOAP API for AccessAgents, as well as AccessAssistant servers, to +authenticate users, and to retrieve and synchronize system and user data. +● Provides Directory Connector SPI (not externalized) to enable integration with various user +repositories. Refer to the IBM Security Access Manager for Enterprise Single Sign-On 8.2 +RCS for the list of out of the box connectors that are provided. +● Provides a web-based UI (called "AccessAdmin") for managing users, machines and system +policies, as well as to query audit logs. +● Creates a user's initial Wallet (including a CSK generated by the Operational Environment +at the TOE's request) when a user account is created via the IMS Server. +Page 10 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Please note that the IMS DB (database) specifically marked in the illustration stores the data +managed by the IMS Server, but the database system is not part of the TOE. +The TOE's IMS Server requires the use of the Microsoft Active Directory directory server in the +evaluated configuration. The TOE can be configured to support password synchronization with +Active Directory. When password synchronization with Active Directory is enabled, the Active +Directory's password quality requirements are enforced by Active Directory, not the TOE. When +password synchronization with Active Directory is disabled, the TOE's password quality requirements +are enforced. +1.5.2.3 AccessAgent +The AccessAgent (AA) is the client software that is installed onto all Windows workstations at the +TOE deployment site, and configured to connect to the designated IMS Server. The AccessAgent +performs the following actions: +● Authenticates the end-user. Optionally, the AccessAgent protects access to the Windows +desktop by replacing the native Microsoft Graphical Identification and Authentication (GINA) +with the IBM Security Access Manager for Enterprise Single Sign-On GINA. +● Performs automated sign-on and sign-off to various applications. The AccessAgent has an +Observer module that is hooked into various applications, and which consults the appropriate +AccessProfile to perform the necessary logon/logoff and automation actions. The +AccessAgent will log onto applications using the appropriate application credential retrieved +from the user's credential Wallet. +● Tracks user application access activities and submits such audit events to the IMS Server. +● Synchronizes AccessProfiles, user's credential Wallet, and various Policy settings with the +IMS Server. +● Provides a UI for end-users to manage the application credentials stored in their credential +Wallet. +● Provides a UI for end-users to manage their own ISAM E-SSO Password. +● Creates a user's initial Wallet (including a CSK generated by the Operational Environment) +when a user sign's up through the AccessAgent. +The AccessAgent can be deployed to Windows workstations with or without GINA replacement (i.e., +in GINA mode or in GINA-less mode). In GINA mode, a user logs on to the IBM Security Access +Manager for Enterprise Single Sign-On (ISAM E-SSO) GINA using his ISAM E-SSO username and +password, whereupon the AccessAgent auto-logons to the Microsoft GINA with the user's Windows +username and password. In GINA-less mode, a user will log on to Windows through the regular +Microsoft GINA with his operating system username and password first, and the AccessAgent will +then use the same credentials to log on the user to his cached Wallet and to the IMS Server. +The AccessAgent will contact the IMS Server upon start up, upon each user logon, as well as on +periodic intervals, to synchronize system and user data changes with the server. However, the +AccessAgent could cache data locally onto the hard disk. As such, it is able to perform most of its +functions even if it is offline to the IMS Server at any point in time. +The AccessAgent relies on its Observer sub-module to perform its single sign-on and workflow +automation features. +The Observer module is composed of an Observer Core module and a number of Observer agent +instances that are hooked (through Windows APIs) into every Windows application (e.g. Lotus Notes, +Outlook, Internet Explorer, etc) launched. +Page 11 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + The behavior of the Observer agent within each specific Application is driven by a set of behavioral +specifications called an AccessProfile. Each AccessProfile is an XML structure (based on a custom +XML language) that provides a declarative set of preconditions (such as the signature of an +application – e.g. name and version of the EXE file), a set of behavioral states (e.g. pre-logon, +post-logon), and with each state, a set of triggers (e.g. when a specific screen is displayed) and +actions (e.g. auto-fill username into a certain field) for the Observer agent to watch for and execute +accordingly. +The Observer agents retrieve the required AccessProfiles as well as user credentials from the +Observer Core module, which in turn communicates with the rest of the AccessAgent for data +synchronization and session management services. +The AccessAgent controls access to a user's Wallet credentials so that only the application specified +by the AccessProfile obtains the user's credentials specified for that application. This Wallet Access +Control Policy is modeled in section 6.1.2.1 and is unique to the AccessAgent. The IMS Server and +other TOE components provide only a supporting role for this policy. +The AccessAgent creates the initial Wallet for a new user when the user sign's up through the +AccessAgent. The Wallet is used to hold the user's credentials for accessing other applications. The +contents of the Wallet are encrypted by the Operational Environment at the request of the TOE +using a 128 bit Common Symmetric Key (CSK). The generation of the CSK is also performed by the +Operational Environment at the request of the TOE. The CSK is encrypted by the Operational +Environment at the request of the TOE with the user's ISAM E-SSO Password and then stored with +the Wallet in a file called a Cryptobox. +AccessAgent allows each user to change his own ISAM E-SSO Password. The TOE's password strength +policies are enforced only when the AccessAgent is in GINA mode with Active Directory password +synchronization disabled. When in GINA-less mode or when Active Directory password synchronization +is enabled, the Active Directory's password strength policy is enforced by Active Directory, not the +TOE. +1.5.2.4 AccessAdmin +The AccessAdmin application is the web-based management console used to administer the IMS +Server, and to manage users (including modifying the role of each user) and policies. +The AccessAdmin application is installed with the IMS Server and allows the Administrator role to: +● Manage user authentication factors. (Only password authentication is allowed in the +evaluated configuration.) +● Manage system, machine, and user policies. +● Manage machine and user groupings. +● Query audit logs; or generate out of the box audit reports +The AccessAdmin application is also used by the Help desk role to: +● Manage user authentication factors. +● Manage user policies. +1.5.2.5 AccessAssistant +The AccessAssistant is the web-based interface used to provide password self-help to end-users. +In the evaluated configuration, it allows a user to: +Page 12 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + ● View and manage passwords for the various application accounts stored in the user's +Wallet. +The AccessAssistant is implemented as a set of servlets that is by default deployed on the IMS +Server. +1.5.2.6 IMS Configuration Utility +The IMS Configuration Utility is the web-based interface used to manage the configuration of the +IMS Server. The IMS Configuration Utility application is installed with the IMS Server and allows the +Administrator role to: +● Manage AccessProfiles +● Manage directory server configurations +● Manage database configurations +1.5.3 TOE boundaries +1.5.3.1 Physical +The TOE is comprised of the following components: +● IMS Server +● AccessAgent +● AccessAdmin +● AccessAssistant +● IMS Configuration Utility +The TOE is software only and is available in download format only from the IBM website. The TOE +installation must include the Fix Packs specified in Table 1. +Name +Type +Component +8.2.0-ISS-SAMESSO-AA-FP0022 +Fix Pack +AccessAgent +8.2.0-ISS-SAMESSO-IMS-IF0004 +Interim Fix +IMS Server +Table 1: Required Fix Packs +The TOE guidance is available online through the Tivoli Software Information Center, except for the +Common Criteria Guide which is available through the software download website. The relevant +guidance documents for the secure operation of the TOE are: +● IBM Security Access Manager for Enterprise Single Sign-On Administrator Guide +● IBM Security Access Manager for Enterprise Single Sign-On User Guide +● IBM Security Access Manager for Enterprise Single Sign-On Quick Start Guide +● IBM Security Access Manager for Enterprise Single Sign-On Common Criteria Guide +Section 1.4.1 lists the Operational Environment software products required by the TOE. +Page 13 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 1.5.3.2 Logical +Due to the nature of the TOE storing, providing, and operating on user credentials for other +applications, the TOE provides a number of security functions. Each security functional complex is +identified and described below: +● Audit - The TOE has the ability to audit the user actions performed by all roles and to store +the records in an audit trail using an external database. The Administrator role has the +ability to review the audit trail using the AccessAdmin component or by using the provided +database views. +● Identification and authentication - The TOE performs the identification and authentication +of all users, regardless of their role, before it allows the user to perform any other actions. +● User credential protection - The TOE stores the user's credentials for third-party applications +in the user's personal Wallet. A Wallet contains the user's arbitrary credentials which are +treated as opaque user data by the TOE. By using encryption mechanisms in the Operational +Environment, the TOE ensures the following: +❍ Only owners have access to credential data. +❍ The Administrator role can reset credential access data and restore use to a Wallet. +❍ A third-party application is given only the credentials which are intended for this +application and stored in the user's Wallet, preventing applications to "impersonate" +as a different application to illicitly obtain credentials. +● Security Management - Role-based access control is used to protect access to operations +in the AccessAdmin and AccessAssistant applications. +All cryptographic operations are performed by the Operational Environment. +1.5.3.3 Evaluated configuration +The following configuration specifics apply to the evaluated configuration of the TOE: +● The use of personal secrets must be disabled. +● Only the AccessAgent plugins provided with the TOE are allowed. +● Only the ISAM E-SSO Password authentication factor is allowed. +● Second factor authentication is disallowed. +● Self-service policies: +❍ Self-service password reset must be disabled. +❍ Self-service authorization code issuance must be disabled. +❍ Self-service registration and bypass of 2nd factor must be disabled. +❍ Self-service registering of additional secrets during sign-up must be disabled. +● The IMS Server's master secret must be protected to only allow the Administrator role +access to it. +● One-Time Passwords (OTPs) must be disabled. +● Mobile ActiveCode (MAC) must be disabled. +● Roaming Desktops (i.e., the use of Microsoft Windows Terminal Server and Citrix +Presentation Server) must be disabled. +● RADIUS authentication must be disabled. +● Windows Fast User Switching must be disabled on Windows 7 systems running AccessAgent. +● Private Desktop must be disabled on Windows XP systems running AccessAgent. +Page 14 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + ● Single sign-on to AccessAdmin when using Microsoft Internet Explorer must be disabled. +● The IMS Server/application must be the only application running in the WebSphere +Application Server (WAS). +● The TOE's password synchronization option with Active Directory affects the security of +the TOE. Specifically, enabling password synchronization with Active Directory will disable +the TOE's ability to enforce password quality requirements. +1.5.4 Security policy model +The security policy for the TOE is defined by the security functional requirements in chapter 6. The +following is a list of the subjects and objects participating in the policy. +Subjects: +● Users +Objects: +● Wallets +● Target applications +TSF data: +● AccessProfiles +● System policies, machine policies, and user policies +● User accounts, including the security attributes defined by FIA_ATD.1 +● Audit records +User data: +● User credential data stored within Wallets. +Page 15 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 2 CC Conformance Claim +This Security Target is CC Part 2 conformant and CC Part 3 conformant, with a claimed Evaluation +Assurance Level of EAL3, augmented by ALC_FLR.1. +This Security Target does not claim conformance to any Protection Profile. +Common Criteria [CC] version 3.1 revision 3 is the basis for this conformance claim. +Page 16 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 3 Security Problem Definition +3.1 Threat Environment +This section describes the threat model for the TOE and identifies the individual threats that are +assumed to exist in the TOE environment. +The assets to be protected by the TOE are the following: +● The IMS Server stores all its data within a relational database. The IMS Server's database +contains essentially these classes of data: +❍ System data - AccessProfiles, system policies, machine policies, user policies, and +other system configuration data +❍ User data - credentials +❍ Audit logs - user activities, administrative activities, SOAP event logs +● Additionally, the AccessAgent caches a subset of system and user data, so that it can +continue to function even when disconnected with the IMS Server. The AccessAgent caches +these data (in encrypted files) on workstations: +❍ System/machine data - AccessProfiles, system policies, machine policies, and user +policies +❍ User data - application credentials +❍ Audit logs - accessing of Wallet, using credentials out of the Wallet to provide to +an application based on the AccessProfiles +The threat agents having an interest in manipulating the data model can be categorized as either: +● Unauthorized individuals ("attackers") which are unknown to the TOE and its runtime +environment +● Authorized users of the TOE who try to manipulate data that they are not authorized to +access +Threat agents originate from a well managed user community within an organizations internal +network. Hence, only inadvertent or casual attempts to breach system security are expected from +this community. +TOE administrators, including administrators of the TOE environment, are assumed to be trustworthy, +trained and to follow the instructions provided to them with respect to the secure configuration +and operation of the systems under their responsibility. Hence, only inadvertent attempts to +manipulate the safe operation of the TOE are expected from this community. +3.1.1 Threats countered by the TOE +T.Manage +A threat agent gains access to the management facilities of the TOE allowing the modification +of the security-relevant configuration of the TOE. +T.UserCredentials +A threat agent gains access to user credentials stored for a user by the TOE. +Page 17 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 3.2 Assumptions +3.2.1 Environment of use of the TOE +3.2.1.1 Physical +A.Physical +It is assumed that the Operational Environment provides the TOE with appropriate physical +security, commensurate with the value of the IT assets protected by the TOE. +3.2.1.2 Personnel +A.AuthUser +Authorized users are expected to act in a cooperating manner in a benign environment. +Users are sufficiently trained and trusted to accomplish some task or group of tasks within +the secure Operational Environment by exercising complete control over their user data. +A.Manage +The TOE security functionality as well as the TOE's underlying systems and of the systems +in the TOE's Operational Environment that are involved in safeguarding TSF data or providing +functionality that the TOE depends on is managed by one or more competent individuals. +The system administrative personnel are not careless, willfully negligent, or hostile, and will +follow and abide by the instructions provided by the guidance documentation. +3.2.1.3 Logical +A.CryptoOps +The cryptographic operations performed by the Operational Environment are performed +according to the specified algorithm standards and the random number generation provides +sufficient randomness and entropy for key generation. +A.Remote +Threat agents are unable to violate the integrity, authenticity, and confidentiality of data +exchanged between the components of the TOE distributed in the deployment infrastructure. +A.Repositories +Threat agents are unable to gain access to TSF data or user data stored in the Operational +Environment, thus bypassing the TSF. +A.Runtime +The machines providing the runtime environment for the IMS Server are assumed to be +used solely for this purpose and not to run other application software except as required +for the support of the TOE and for the management and maintenance of the underlying +system and hardware. Especially, it is assumed that the underlying systems are configured +in a way that prevents unauthorized access to security functions provided by or protected +by the runtime environment either locally or via any network based connections. +Page 18 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + A.System +Threat agents are unable to circumvent the TSF by penetrating or manipulating the runtime +environment of the TOE and gain access to TSF or user data. +3.3 Organizational Security Policies +P.Accountability +Administrators and users are to be held accountable for security-relevant actions with the +TOE. +P.PasswordQuality +The quality of the ISAM E-SSO Password protecting the Common Symmetric Key (CSK) must +possess the strength to prevent credential guessing from threat agents. +P.User +Any user is trusted to perform the actions for which they have been authorized to perform. +Authorized users possess the necessary authorization to perform at least one operation on +the information managed by the TOE. +Page 19 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 4 Security Objectives +4.1 Objectives for the TOE +O.AccessProfiles +The TOE must only releases a subset of the credential information stored in a user's Wallet +to the target application the user intends to identify and authenticate to based on +AccessProfiles. +O.Audit +The TOE shall offer an audit mechanism that can be used to hold users of each role +accountable for security-relevant actions performed with the TSF. Security-relevant actions +audited by the audit mechanism shall include password changes and the accessing of Wallets. +Each audit record generated by the audit mechanism shall contain the time and date that +the event occurred. The TOE shall provide a mechanism for authorized users to review the +generated audit records. +O.Authentication +The TOE must ensure that only authorized users gain access to the TOE and its resources. +O.Manage +The TSF must provide all the functions and facilities necessary to support the authorized +users that are responsible for the management of TOE security mechanisms and must ensure +that only authorized users are able to access such functionality. +O.Role +The TOE must assign a role to each user after successful identification and authentication +to the management facility. This role limits the management actions the user is allowed to +perform. +O.PasswordQuality +When in GINA mode with Active Directory password synchronization disabled, the TOE must +ensure that the quality of the ISAM E-SSO Password protecting the Common Symmetric Key +(CSK) must possess the strength to prevent credential guessing from threat agents. +O.WalletAccess +The TOE must ensure that users can only access the contents of the Wallet assigned to +them. +4.2 Objectives for the Operational Environment +OE.CryptoOps +The cryptographic operations performed by the Operational Environment shall perform +according to the specified algorithm standards and the random number generation shall +provide sufficient randomness and entropy for key generation. +Page 20 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + OE.InfoProtect +Those responsible for the TOE must be competent individuals, not careless, willfully negligent, +or hostile. They must follow and abide by the instructions provided by the guidance +documentation. They must establish and implement procedures to ensure that information +is protected in an appropriate manner. In particular: +● All network communication channels and peripheral link must be approved for the +transmittal of the most sensitive data held by the system. Such links are assumed +to be adequately protected against threats to the authenticity, confidentiality and +integrity of the data transmitted. +● All repositories holding TSF data and user data stored in the Operational Environment +are access protected to restrict access to the TSF only. +OE.PasswordQuality +When either in GINA mode with Active Directory password synchronization enabled or when +in GINA-less mode, the runtime environment must ensure that the quality of the ISAM E-SSO +Password protecting the Common Symmetric Key (CSK) must possess the strength to prevent +credential guessing from threat agents. +OE.Physical +Those responsible for the TOE must ensure that those parts of the TOE critical to security +policy are protected from physical attack which might compromise IT security objectives. +The protection must commensurate with the value of the IT assets protected by the TOE. +OE.Runtime +The runtime environment used for all components of the TOE must be properly administered +and protected from interference by unauthorized entities. This includes the requirement +that the system(s) hosting components of the IMS Server are restricted to be used for this +purpose only. +OE.TimeSource +The runtime environment shall provide a reliable time source for the TOE's use. +OE.Users +The TOE users shall act in a cooperating manner in a benign environment. The TOE users +shall be trained and trusted to accomplish some task or group of tasks within the secure +Operational Environment by exercising complete control over their user data. +4.3 Security Objectives Rationale +4.3.1 Security objectives coverage +The following table provides a mapping of TOE objectives to threats and policies, showing that each +objective counters or enforces at least one threat or policy, respectively. +Page 21 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Threats / OSPs +Objective +T.UserCredentials +O.AccessProfiles +P.Accountability +O.Audit +T.Manage +O.Authentication +T.Manage +O.Manage +T.Manage +P.User +O.Role +P.PasswordQuality +O.PasswordQuality +T.UserCredentials +O.WalletAccess +Table 2: Mapping of security objectives to threats and policies +The following table provides a mapping of the objectives for the Operational Environment to +assumptions, threats and policies, showing that each objective holds, counters or enforces at least +one assumption, threat or policy, respectively. +Assumptions / Threats / OSPs +Objective +A.CryptoOps +OE.CryptoOps +A.Manage +A.Remote +A.Repositories +OE.InfoProtect +P.PasswordQuality +OE.PasswordQuality +A.Physical +OE.Physical +A.Runtime +A.System +OE.Runtime +P.Accountability +OE.TimeSource +A.AuthUser +OE.Users +Table 3: Mapping of security objectives for the Operational Environment to assumptions, +threats and policies +4.3.2 Security objectives sufficiency +The following rationale provides justification that the security objectives are suitable to counter +each individual threat and that each security objective tracing back to a threat, when achieved, +actually contributes to the removal, diminishing or mitigation of that threat: +Page 22 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Rationale for security objectives +Threat +The threat of unauthorized access to the management facilities of the +TOE is diminished by the objective O.Manage which specifies that specific +management facilities exist. +T.Manage +In addition, a role mechanism is enforced for users with O.Role which +supports the protection of the management facilities by limiting +management capabilities of users to their role. +For enforcing the role-based management mechanism, the TOE provides +an identification and authentication mechanism for users with +O.Authentication to allow the TOE to establish the user identity and the +associated role for that user. +The threat of unauthorized access to the credential data stored for a +user by the TOE is diminished by the objective O.AccessProfiles which +ensures that the TOE releases only the credentials required for a target +T.UserCredentials +application to the target application based on the AccessProfiles. An +AccessProfile restricts other credentials in the Wallet from being +decrypted by the Operational Environment and passed to a target +application by mapping Wallet credentials to target applications. In +addition, AccessProfiles provide methods to identify applications in order +to prevent a threat agent from using a spoof or rogue application to +obtain a user's credentials. +In addition, the TOE implements per-user Wallets which the user must +access using his ISAM E-SSO Password as specified with O.WalletAccess, +ensuring that only the owner of a Wallet can access the user's Wallet +holding the user's credentials. +Table 4: Sufficiency of objectives countering threats +The following rationale provides justification that the security objectives for the environment are +suitable to cover each individual assumption, that each security objective for the environment that +traces back to an assumption about the environment of use of the TOE, when achieved, actually +contributes to the environment achieving consistency with the assumption, and that if all security +objectives for the environment that trace back to an assumption are achieved, the intended usage +is supported: +Rationale for security objectives +Assumption +The assumption on physical protection of the TOE is achieved by the +environmental objective OE.Physical to provide such protection. +A.Physical +The assumption that authorized users are cooperative, trained, and +trusted is covered by the environmental objective OE.Users which +requires that the TOE users shall act in a cooperating manner in a benign +A.AuthUser +environment and the TOE users shall be trained and trusted to accomplish +some task or group of tasks within the secure Operational Environment +by exercising complete control over their user data. +Page 23 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Rationale for security objectives +Assumption +The assumptions that the management of the TOE and the underlying +environment is conducted by competent individuals who are not careless, +willfully negligent, or hostile, and will follow and abide by the instructions +A.Manage +provided by the guidance documentation are achieved by the +environmental objective OE.InfoProtect to ensure these properties of +administrators. +The assumptions that the cryptographic operations performed by the +Operational Environment are performed according to the specified +algorithm standards and the random number generation provides +A.CryptoOps +sufficient randomness and entropy for key generation are achieved by +the environmental objective OE.CryptoOps which states that the +cryptographic operations performed by the Operational Environment +shall perform according to the specified algorithm standards and the +random number generation shall provide sufficient randomness and +entropy for key generation. +The assumption that threat agents are unable to compromise the +exchange of data between the different distributed TOE components is +achieved by the environmental objective OE.InfoProtect which guarantees +A.Remote +that the environment protects these communication channels either by +physical means (such as dedicated network links to which routing from +outside networks is prohibited) or by logical means (such as the use of +cryptographically secured network channels). +The assumption that threat agents are unable to access the TOE +repositories holding TSF data and user data and bypass the TSF is +achieved by the environmental objective OE.InfoProtect which requires +an appropriate access restriction of those repositories to the TSF. +A.Repositories +The assumption on exclusive TOE use of the underlying machines for +the IMS Server and preventing unauthorized access to the TOE is +achieved by the environmental objective OE.Runtime to implement +corresponding measures for the server runtime environment. +A.Runtime +The assumption that threat agents are unable to manipulate the runtime +environment to circumvent the TSF is achieved by OE.Runtime which +specifies that this runtime environment must be properly administered +and protected from interference by unauthorized entities. +A.System +Table 5: Sufficiency of objectives holding assumptions +The following rationale provides justification that the security objectives are suitable to cover each +individual organizational security policy, that each security objective that traces back to an OSP, +when achieved, actually contributes to the implementation of the OSP, and that if all security +objectives that trace back to an OSP are achieved, the OSP is implemented: +Page 24 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Rationale for security objectives +OSP +The policy to provide accountability for the action of TOE administrators +and users is implemented by the objective O.Audit to provide an auditing +mechanism and supported by the environmental objective OE.TimeSource +to provide a reliable time source in the runtime environment. +P.Accountability +The policy that the ISAM E-SSO Password must possess the strength to +prevent credential guessing from threat agents is achieved by the +objectives O.PasswordQuality and OE.PasswordQuality which require +either the TOE or the runtime environment, respectively, to enforce the +password strength depending on the TOE's configuration. +P.PasswordQuality +The policy that users are trusted to perform the actions for which they +have been authorized to perform is achieved by the objective O.Role +which ensures that the TOE assigns a role to every user identifying and +authenticating with the TOE management facilities. +P.User +Table 6: Sufficiency of objectives enforcing Organizational Security Policies +Page 25 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 5 Extended Components Definition +This Security Target does not extend the security components provided by the Common Criteria. +Page 26 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 6 Security Requirements +6.1 TOE Security Functional Requirements +The following table shows the security functional requirements for the TOE, and the operations +performed on the components according to CC part 2: iteration (Iter.), refinement (Ref.), assignment +(Ass.) and selection (Sel.). +Operations +Source +Security functional requirement +Security +functional +group Sel. +Ass. +Ref. +Iter. +Yes +Yes +No +No +CC Part 2 +FAU_GEN.1 Audit data generation +FAU - Security +audit +No +No +No +No +CC Part 2 +FAU_GEN.2 User identity association +No +Yes +Yes +No +CC Part 2 +FAU_SAR.1 Audit review +No +No +No +No +CC Part 2 +FAU_SAR.2 Restricted audit review +Yes +No +No +No +CC Part 2 +FAU_STG.1 Protected audit trail storage +No +Yes +No +No +CC Part 2 +FDP_ACC.2 Subset access control +FDP - User data +protection +No +Yes +No +No +CC Part 2 +FDP_ACF.1 Security attribute based access control +No +Yes +No +No +CC Part 2 +FIA_ATD.1 User attribute definition +FIA - Identification +and +authentication No +Yes +No +No +CC Part 2 +FIA_SOS.1 Verification of secrets +No +No +No +No +CC Part 2 +FIA_UAU.2 User authentication before any action +No +No +No +No +CC Part 2 +FIA_UID.2 User identification before any action +No +Yes +No +No +CC Part 2 +FIA_USB.1 User-subject binding +Yes +Yes +No +No +CC Part 2 +FMT_MSA.1 Management of security attributes +FMT - Security +management +Yes +Yes +No +No +CC Part 2 +FMT_MSA.3 Static attribute initialisation +Yes +Yes +No +No +CC Part 2 +FMT_MTD.1 Management of TSF data +No +Yes +No +No +CC Part 2 +FMT_SMF.1 Specification of management functions +No +Yes +No +No +CC Part 2 +FMT_SMR.1 Security roles +Table 7: Security functional requirements for the TOE +Page 27 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 6.1.1 Security audit (FAU) +6.1.1.1 Audit data generation (FAU_GEN.1) +The TSF shall be able to generate an audit record of the following auditable events: +a) Start-up and shutdown of the audit functions; +b) All auditable events for the not specified level of audit; and +c) the following auditable events: +FAU_GEN.1.1 +● IMS Server: logins, password changes, role changes, policy changes +(for machine, system and user policies); +● AccessAgent: accessing of the Wallet, using credentials out of the +Wallet to provide to an application based on the AccessProfiles, +password changes. +Application note: The requirement to log startup and shutdown of the audit +functions is trivially satisfied as the audit system is running when the TOE runs +and cannot be turned off. +The TSF shall record within each audit record at least the following information: +a) Date and time of the event, type of event, subject identity (if applicable), and +the outcome (success or failure) of the event; and +b) For each audit event type, based on the auditable event definitions of the +functional components included in the PP/ST, no other information. +FAU_GEN.1.2 +6.1.1.2 User identity association (FAU_GEN.2) +For audit events resulting from actions of identified users, the TSF shall be able +to associate each auditable event with the identity of the user that caused the +event. +FAU_GEN.2.1 +6.1.1.3 Audit review (FAU_SAR.1) +The TSF shall provide users assigned to the Administrator role with the +capability to read all audit data from the audit records generated by the following +audit events: +FAU_SAR.1.1 +● IMS Server: logins, policy changes (for system and user policies only); +● AccessAgent: accessing of the Wallet, using credentials out of the Wallet to +provide to an application based on the AccessProfiles. +The TSF shall provide the audit records in a manner suitable for the user to +interpret the information. +FAU_SAR.1.2 +Application Note: The functionality of FAU_SAR.1 is provided by AccessAdmin. +6.1.1.4 Restricted audit review (FAU_SAR.2) +The TSF shall prohibit all users read access to the audit records, except those +users that have been granted explicit read-access. +FAU_SAR.2.1 +Page 28 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 6.1.1.5 Protected audit trail storage (FAU_STG.1) +The TSF shall protect the stored audit records in the audit trail from unauthorised +deletion. +FAU_STG.1.1 +The TSF shall be able to prevent unauthorised modifications to the stored audit +records in the audit trail. +FAU_STG.1.2 +6.1.2 User data protection (FDP) +6.1.2.1 Subset access control (FDP_ACC.2) +Wallet Access Control Policy +Definition +Short name +Type +A TOE user. +S_User +Subjects +A target application. +O_TargetApp +Objects +A user's Wallet. +O_Wallet +Decrypt the user's Common Symmetric Key (CSK) and the +user's target application credentials (using cryptographic +operations supplied by the Operational Environment). +Decrypt +Operations +Release the user's target application credentials for the +specified target application. +Release +A user's ISAM E-SSO Password for decrypting the user's +CSK. +AS_Password +Security +attributes of +subjects +The AccessProfile for the target application. +AO_AccessProfile +Security +attributes of +objects The user's CSK. +AO_CSK +If the user's CSK can be successfully decrypted by the +Operational Environment using a key derived from the +user's ISAM E-SSO Password, then the TOE provides the +user access to the user's Wallet; otherwise, access to the +user's Wallet is denied. +R_DecryptCSK +Rules +If the target application's AccessProfile key is found in the +user's Wallet, the user's credentials for only the target +application are decrypted by the Operational Environment +R_ReleaseCreds +using the user's CSK and released to the target application; +otherwise, no credentials are released to the target +application. +Table 8: Wallet Access Control Policy +The TSF shall enforce the Wallet Access Control Policy in Table 8 on subjects +and objects as defined in Table 8 and all operations among subjects and +objects covered by the SFP. +FDP_ACC.2.1 +Page 29 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + The TSF shall ensure that all operations between any subject controlled by the +TSF and any object controlled by the TSF are covered by an access control SFP. +FDP_ACC.2.2 +Application Note: An AccessProfile key is a key created from information specific to an interface +(e.g., a program's pathname and filename) that is used to reference the user's credentials for that +program in the user's Wallet. +Application Note: The Wallet Access Control Policy defined in FDP_ACC.2 is only enforced by the +AccessAgent. (The IMS Server does not enforce this policy.) +6.1.2.2 Security attribute based access control (FDP_ACF.1) +The TSF shall enforce the Wallet Access Control Policy in Table 8 to objects +based on the following: subjects, objects, and for each the security +attributes as defined in Table 8. +FDP_ACF.1.1 +The TSF shall enforce the following rules to determine if an operation among +controlled subjects and controlled objects is allowed: rules as defined in Table +8 performed in the following order: +FDP_ACF.1.2 +1. R_DecryptCSK; +2. R_ReleaseCreds. +The TSF shall explicitly authorize access of subjects to objects based on the +following additional rules: none. +FDP_ACF.1.3 +The TSF shall explicitly deny access of subjects to objects based on the following +additional rules: none. +FDP_ACF.1.4 +6.1.3 Identification and authentication (FIA) +6.1.3.1 User attribute definition (FIA_ATD.1) +The TSF shall maintain the following list of security attributes belonging to +individual users: +FIA_ATD.1.1 +● User identifier; +● Common Symmetric Key (CSK); +● Role. +6.1.3.2 Verification of secrets (FIA_SOS.1) +The TSF shall provide a mechanism to verify that secrets meet the following: +FIA_SOS.1.1 +● For each attempt to use the authentication mechanism, the +probability that a random attempt will succeed is less than one in +1,000,000; +● For multiple attempts to use the authentication mechanism during +a one minute period, the probability that a random attempt during +that minute will succeed is less than one in 100,000; and +● Any feedback given during an attempt to use the authentication +mechanism will not reduce the probability below the above metrics. +Page 30 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Application Note: The password strength policies are enforced by the TOE only when the TOE is +in GINA mode with Active Directory password synchronization disabled. The password strength +policies are not enforced when the TOE is in GINA-less mode. +6.1.3.3 User authentication before any action (FIA_UAU.2) +The TSF shall require each user to be successfully authenticated before allowing +any other TSF-mediated actions on behalf of that user. +FIA_UAU.2.1 +6.1.3.4 User identification before any action (FIA_UID.2) +The TSF shall require each user to be successfully identified before allowing any +other TSF-mediated actions on behalf of that user. +FIA_UID.2.1 +6.1.3.5 User-subject binding (FIA_USB.1) +The TSF shall associate the following user security attributes with subjects acting +on the behalf of that user: +FIA_USB.1.1 +● User identifier (which is associated with auditable events); +● Role. +The TSF shall enforce the following rules on the initial association of user security +attributes with subjects acting on the behalf of users: +FIA_USB.1.2 +● The IMS Server and all associated management interfaces: After +successful identification and authentication, the user identifier and +the role associated with the new session are set based on the +identifier and role specified for the user entry of the successfully +authenticated user. +● AccessAgent: After successful identification and authentication, the +user identifier associated with the new session is set based on the +identifier specified for the user entry of the successfully +authenticated user. +The TSF shall enforce the following rules governing changes to the user security +attributes associated with subjects acting on the behalf of users: none. +FIA_USB.1.3 +6.1.4 Security management (FMT) +6.1.4.1 Management of security attributes (FMT_MSA.1) +Wallet Access Control Policy management +Authorized users and roles +Security attributes +Operations +Administrator role +AccessProfile +Add, modify +Users who know the current ISAM E-SSO Password for the +user's CSK +ISAM E-SSO Password +Modify +Table 9: Wallet Access Control Policy management +Page 31 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + The TSF shall enforce the Wallet Access Control Policy in Table 8 to restrict +the ability to perform the operations as defined in Table 9 on the security +attributes as defined in Table 9 to the authorized users and roles as +defined in Table 9. +FMT_MSA.1.1 +Application Note: To add and modify AccessProfiles, the IMS Configuration Utility is used. To +modify ISAM E-SSO Passwords, AccessAgent is used. +6.1.4.2 Static attribute initialisation (FMT_MSA.3) +The TSF shall enforce the Wallet Access Control Policy in Table 8 to provide +restrictive default values for security attributes that are used to enforce the +SFP. +FMT_MSA.3.1 +The TSF shall allow nobody to specify alternative initial values to override the +default values when an object or information is created. +FMT_MSA.3.2 +6.1.4.3 Management of TSF data (FMT_MTD.1) +TSF data management +Authorized roles +TSF data +Operations +Administrator +Role user security attribute +Modify +Administrator +System policies and machine policies +Modify +Administrator and Help desk +System policies and machine policies +View +Administrator and Help desk +User policies +Modify, view +Table 10: TSF data management +The TSF shall restrict the ability to perform the operations in Table 10 on +the TSF data in Table 10 to the authorized roles in Table 10. +FMT_MTD.1.1 +Application Note: To perform the operations on the TSF data specified in Table 10, AccessAdmin +is used. +6.1.4.4 Specification of management functions (FMT_SMF.1) +The TSF shall be capable of performing the following management functions: +FMT_SMF.1.1 +● Assign roles to users (see FMT_MTD.1); +● Manage machine, system, and user policies (see FMT_MTD.1); +● View audit logs (see FAU_SAR.1). +6.1.4.5 Security roles (FMT_SMR.1) +The TSF shall maintain the roles +FMT_SMR.1.1 +● Administrator; +● Help desk; +● User. +Page 32 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + The TSF shall be able to associate users with roles. +FMT_SMR.1.2 +6.2 Security Functional Requirements Rationale +6.2.1 Security requirements coverage +The following table provides a mapping of SFR to the security objectives, showing that each security +functional requirement addresses at least one security objective. +Objectives +Security functional requirements +O.Audit +FAU_GEN.1 +O.Audit +FAU_GEN.2 +O.Audit +FAU_SAR.1 +O.Audit +FAU_SAR.2 +O.Audit +FAU_STG.1 +O.AccessProfiles, +O.WalletAccess +FDP_ACC.2 +O.AccessProfiles, +O.WalletAccess +FDP_ACF.1 +O.Authentication +FIA_ATD.1 +O.PasswordQuality +FIA_SOS.1 +O.Authentication +FIA_UAU.2 +O.Authentication +FIA_UID.2 +O.Audit, +O.Authentication +FIA_USB.1 +O.Manage +FMT_MSA.1 +O.Manage +FMT_MSA.3 +O.Manage +FMT_MTD.1 +O.Manage +FMT_SMF.1 +O.Role +FMT_SMR.1 +Table 11: Mapping of security functional requirements to security objectives +6.2.2 Security requirements sufficiency +The following rationale provides justification for each security objective for the TOE, showing that +the security functional requirements are suitable to meet and achieve the security objectives: +Page 33 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Rationale +Security objectives +The access control policy specified with FDP_ACC.2 and FDP_ACF.1 +ensures that only the intended credentials are released to the target +application. +O.AccessProfiles +The objective to provide means to audit security-relevant actions with +the TSF is met by requirements for audit record generation (FAU_GEN.1) +and association of audited events with the originating user ID +O.Audit +(FAU_GEN.2). Administrators have the ability to review audit data +(FAU_SAR.1). The audit data is stored in a protected environment +(FAU_STG.1) and the TOE ensures that it can only be read by authorized +users (FAU_SAR.2). Users are identified based on the established identity +during user-subject-binding (FIA_USB.1). +The TOE environment needs to provide the proper time for the generated +audit records, see OE.TimeSource. +Supportive management functions have been specified in FMT_SMF.1. +Identification and authentication is a prerequisite for the management +function and is defined with FIA_UAU.2 and FIA_UID.2. After the successful +identification and authentication, the TOE performs a user-subject-binding +as defined with FIA_USB.1. The security attributes maintained by the +TOE and used for the user-subject-binding are listed in FIA_ATD.1. +O.Authentication +The general management functions provided with the TOE are listed in +FMT_SMF.1 and detailed in FMT_MTD.1. In addition, the management of +user Wallets is defined with FMT_MSA.1 and FMT_MSA.3. +O.Manage +The definition of roles known to the TSF is specified with FMT_SMR.1. +O.Role +When in GINA mode with Active Directory password synchronization +disabled, the TOE ensures that the quality of the ISAM E-SSO Password +protecting the Common Symmetric Key (CSK), as specified by FIA_SOS.1, +must possess the strength to prevent credential guessing from threat +agents. +O.PasswordQuality +The access control policy specified with FDP_ACC.2 and FDP_ACF.1 +ensures that users can only access their Wallet. +O.WalletAccess +Table 12: Security objectives for the TOE rationale +6.2.3 Security requirements dependency analysis +The following table demonstrates the dependencies of SFRs modeled in CC Part 2 and how the SFRs +for the TOE resolve those dependencies: +Page 34 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Resolution +Dependencies +Security +Functional +Requirement +The TOE is application software and, +therefore, cannot provide reliable time +stamps. Reliable time stamps must be +provided by the Operational Environment. +See OE.TimeSource. +FPT_STM.1 +FAU_GEN.1 +FAU_GEN.1 +FAU_GEN.1 +FAU_GEN.2 +FIA_UID.2 +FIA_UID.1 +FAU_GEN.1 +FAU_GEN.1 +FAU_SAR.1 +FAU_SAR.1 +FAU_SAR.1 +FAU_SAR.2 +FAU_GEN.1 +FAU_GEN.1 +FAU_STG.1 +FDP_ACF.1 +FDP_ACF.1 +FDP_ACC.2 +FDP_ACC.2 +FDP_ACC.1 +FDP_ACF.1 +FMT_MSA.3 +FMT_MSA.3 +No dependencies. +FIA_ATD.1 +No dependencies. +FIA_SOS.1 +FIA_UID.2 +FIA_UID.1 +FIA_UAU.2 +No dependencies. +FIA_UID.2 +FIA_ATD.1 +FIA_ATD.1 +FIA_USB.1 +FDP_ACC.2 +[FDP_ACC.1 or FDP_IFC.1] +FMT_MSA.1 +FMT_SMR.1 +FMT_SMR.1 +FMT_SMF.1 +FMT_SMF.1 +FMT_MSA.1 +FMT_MSA.1 +FMT_MSA.3 +FMT_SMR.1 +FMT_SMR.1 +FMT_SMR.1 +FMT_SMR.1 +FMT_MTD.1 +FMT_SMF.1 +FMT_SMF.1 +No dependencies. +FMT_SMF.1 +FIA_UID.2 +FIA_UID.1 +FMT_SMR.1 +Table 13: TOE SFR dependency analysis +Page 35 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 6.3 Security Assurance Requirements +The security assurance requirements for the TOE are the Evaluation Assurance Level 3 components +as specified in [CC] part 3, augmented by ALC_FLR.1. +The following table shows the Security assurance requirements, and the operations performed on +the components according to CC part 3: iteration (Iter.), refinement (Ref.), assignment (Ass.) and +selection (Sel.). +Operations +Source +Security assurance requirement +Security +assurance class +Sel. +Ass. +Ref. +Iter. +No +No +No +No +CC Part 3 +ADV_ARC.1 Security architecture description +ADV Development +No +No +No +No +CC Part 3 +ADV_FSP.3 Functional specification with complete +summary +No +No +No +No +CC Part 3 +ADV_TDS.2 Architectural design +No +No +No +No +CC Part 3 +AGD_OPE.1 Operational user guidance +AGD Guidance +documents +No +No +No +No +CC Part 3 +AGD_PRE.1 Preparative procedures +No +No +No +No +CC Part 3 +ALC_CMC.3 Authorisation controls +ALC Life-cycle +support +No +No +No +No +CC Part 3 +ALC_CMS.3 Implementation representation CM +coverage +No +No +No +No +CC Part 3 +ALC_DEL.1 Delivery procedures +No +No +No +No +CC Part 3 +ALC_DVS.1 Identification of security measures +No +No +No +No +CC Part 3 +ALC_FLR.1 Basic flaw remediation +No +No +No +No +CC Part 3 +ALC_LCD.1 Developer defined life-cycle model +No +No +No +No +CC Part 3 +ASE_INT.1 ST introduction +ASE Security +Target evaluation +No +No +No +No +CC Part 3 +ASE_CCL.1 Conformance claims +No +No +No +No +CC Part 3 +ASE_SPD.1 Security problem definition +No +No +No +No +CC Part 3 +ASE_OBJ.2 Security objectives +No +No +No +No +CC Part 3 +ASE_ECD.1 Extended components definition +No +No +No +No +CC Part 3 +ASE_REQ.2 Derived security requirements +No +No +No +No +CC Part 3 +ASE_TSS.1 TOE summary specification +No +No +No +No +CC Part 3 +ATE_COV.2 Analysis of coverage +ATE Tests +No +No +No +No +CC Part 3 +ATE_DPT.1 Testing: basic design +No +No +No +No +CC Part 3 +ATE_FUN.1 Functional testing +No +No +No +No +CC Part 3 +ATE_IND.2 Independent testing - sample +Page 36 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + Operations +Source +Security assurance requirement +Security +assurance class +Sel. +Ass. +Ref. +Iter. +No +No +No +No +CC Part 3 +AVA_VAN.2 Vulnerability analysis +AVA Vulnerability +assessment +Table 14: Security assurance requirements +6.4 Security Assurance Requirements Rationale +The evaluation assurance level has been chosen to match a Basic attack potential commensurate +with the threat environment that is experienced by typical consumers of the TOE. In addition, the +evaluation assurance level has been augmented with ALC_FLR.1 commensurate with the augmented +flaw remediation capabilities offered by the developer beyond those required by the evaluation +assurance level. +Page 37 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 7 TOE Summary Specification +7.1 TOE Security Functionality +The following section explains how the security functions are implemented. The different TOE +security functions cover the various SFR classes. +The primary security features of the TOE are: +● Audit +● Identification and Authentication +● User Data Protection +● Security Management +Of the policies referred to in the sections below, only the password strength policies are evaluated +by this evaluation. +7.1.1 Audit +Various components of the product generate audit events which are stored in the IMS Server +database. +All user application access logs are collated into the IMS Server's audit log database. Each log record +contains info related to time and location from which a user accesses a certain application. Using +AccessAdmin, the Administrator role can generate reports to review the logs contained in the +database. Several predefined audit reports come standard with the TOE. Only users with the +Administrator role are allowed access to the audit records via the TOE, preventing both unauthorized +access to and unauthorized deletion of the stored audit records. +The TOE provides audit records for the following types of events besides the start-up and shutdown +of the audit functions: +● IMS Server: +❍ logins +❍ password changes +❍ role changes +❍ policy changes (for machine, system and user policies) +● AccessAgent: +❍ accessing of the Wallet +❍ using credentials out of the Wallet to provide to an application based on the +AccessProfiles +❍ password changes +The audit records include the date and time of the event, the type of event, the subject identity +and the event outcome. The audit record time stamps are obtained from a reliable time source in +the Operational Environment. +The Administrator role can view and search a subset of the audit records through the TOE using +AccessAdmin. The subset that can be viewed and searched are: +● IMS Server: +❍ logins +❍ policy changes (for system and user policies only) +Page 38 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + ● AccessAgent: +❍ accessing of the Wallet +❍ using credentials out of the Wallet to provide to an application based on the +AccessProfiles +This section maps to the following SFR(s): +● FAU_GEN.1 +● FAU_GEN.2 +● FAU_SAR.1 +● FAU_SAR.2 +● FAU_STG.1 +7.1.2 Identification and authentication (I&A) +The TOE supports an identification mechanism and an authentication mechanism. This section +describes the supported mechanism. +The TOE maintains its own user repository, and performs user authentication against various forms +of authentication credentials stored in this repository (stored in the IMS Server database). The +user's ISAM E-SSO Password is created when the account is first created (when the user first sign's +up). +The user's Wallet, which contains his authentication data, is stored centrally in the IMS Server +database. Additionally, the authentication data is cached onto the user's workstation disk whenever +the user caches his Wallet to a machine. This allows the AccessAgent to be able to authenticate +users even when the machine cannot connect to the IMS Server. +An enterprise can ensure that its users use strong passwords to log on to the TOE by enforcing +ISAM E-SSO Password strength policies. +7.1.2.1 AccessAgent +AccessAgent is a Windows application. It authenticates users based on their user identifier and +password. A unique-per-user, 128 bit Common Symmetric Key (CSK) is generated by the Operational +Environment at the request the AccessAgent for the user when the user initially sign's up through +the AccessAgent. This CSK is associated with the user's account and is maintained by the TOE in +the Cryptobox that contains the user's Wallet. The TOE passes the user's password along with the +user's encrypted Common Symmetric Key (CSK) from the Cryptobox to the cryptographic operations +in the Operational Environment to obtain the user's CSK. The user is considered authenticated by +the TOE if the user's CSK is successfully obtained. (Authentication with one-time passwords (OTP) +is disabled in the evaluated configuration.) +If the AccessAgent has a network connection to the IMS Server, it will authenticate a user against +the user's credentials stored in the IMS Server, by passing along the authentication credentials +over HTTPS to the IMS Server. However, if the AccessAgent is offline to the IMS Server, it will then +authenticate the user's presented credentials against cached authentication data stored on the +disk in the user's Cryptobox. +For AccessAgents installed with the GINA option enabled (i.e., in GINA mode), a user will log on to +the AccessAgent GINA first, whereupon the AccessAgent will auto-logon the user into Windows +using the user's Windows account. +Page 39 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + For AccessAgents installed with the GINA option disabled (i.e., in GINA-less mode), the user will log +on to Windows manually first, and then the AccessAgent will auto-logon the user into his Wallet. +Authentication of users by the AccessAgent is carried out in accordance to Authentication Policies +defined by the Administrator role at the IMS Server and sync-ed to various AccessAgents. +AccessAgent allows each user to change his own ISAM E-SSO Password. The TOE's password strength +policies are enforced only when the AccessAgent is in GINA mode with Active Directory password +synchronization disabled. When in GINA-less mode or when Active Directory password synchronization +is enabled, the Active Directory's password strength policy is enforced by Active Directory, not the +TOE. +This section and its subsections map to the following SFR(s): +● FIA_ATD.1 +● FIA_SOS.1 +● FIA_UAU.2 +● FIA_UID.2 +● FIA_USB.1 +7.1.2.2 AccessAssistant +Users perform form-based logon to AccessAssistant using their username and ISAM E-SSO Password. +The AccessAssistant authenticates a user by making SOAP-based logon calls, with the user-provided +credentials, to the IMS Server, where the credentials are verified against the authentication data +stored in the IMS Server database. +This section and its subsections map to the following SFR(s): +● FIA_ATD.1 +● FIA_UAU.2 +● FIA_UID.2 +● FIA_USB.1 +7.1.2.3 AccessAdmin +Only users who are assigned Administrator or Help desk roles can log on to AccessAdmin. Users +authenticate to AccessAdmin using the following method: +● Form-based logon (over HTTPS) using a username and ISAM E-SSO Password. +The authentication and access control is implemented by the AccessAdmin/IMS application, which +will lookup the user's authentication data as well as assigned roles stored in the IMS Server database. +This section and its subsections map to the following SFR(s): +● FIA_ATD.1 +● FIA_UAU.2 +● FIA_UID.2 +● FIA_USB.1 +7.1.2.4 IMS Configuration Utility +The IMS Configuration Utility is a web-based utility for editing the IMS Server's configuration. It uses +authentication and access control provided by the Operational Environment. +Page 40 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 7.1.3 User data protection +The TOE supports a user data protection mechanism. This section describes the supported +mechanism. +The TOE stores each user's credential data in a Wallet; one Wallet per-user. A Wallet provides +confidentiality and integrity protection of the user credential data through the use of cryptographic +operations. All cryptographic operations are performed by the Operational Environment. +When a user sign's up via the TOE, the TOE creates a Wallet for the user and has the Operational +Environment generate a 128 bit cryptographic key called the Common Symmetric Key (CSK). +The CSK is unique for each user and is used for encrypting the user's credential data stored in the +user's Wallet. The CSK, in turn, is encrypted with a key derived from the user's ISAM E-SSO Password +using AES 128 bit Cipher Block Chaining (CBC) mode. To decrypt items in the user's Wallet, the +user supplies a valid ISAM E-SSO Password. The TOE provides the user's ISAM E-SSO Password and +the user's encrypted CSK as input to cryptographic operations in the Operational Environment to +obtain the CSK. The TOE then passes this CSK and an encrypted Wallet Credential from the user's +Wallet as input to cryptographic operations in the Operational Environment to obtain a decrypted +Wallet credential. For a user to change/modify the password of a Wallet, the user must know the +current password for the TOE initiated decryption operations to succeed and to obtain the CSK. The +AccessAgent allows each user to change his own ISAM E-SSO Password. +Both the Wallet and the password-encrypted CSK are stored in a secure data file on the AccessAgent +called a Cryptobox; one Cryptobox per-user. The information in the Cryptobox is sent to the IMS +Server for storage. +Since the CSK is required to access the credentials in the user's Wallet and the CSK is encrypted +with the user's ISAM E-SSO Password, the TOE does not store user ISAM E-SSO Paswords anywhere +in the system. Instead, the TOE requires users to supply their ISAM E-SSO Passwords each time +they log in. +The IMS Server stores only the encrypted forms of the user's credential data and CSK. By default, +the access controls on the IMS Server database are configured such that only an IMS Server-specific +database account, and the database administrators are allowed to access the data. +Each Cryptobox file and its containing folder are protected by Windows ACLs, so normal Windows +users will not be able to read and/or copy the files. +The AccessAgent's Single Sign-On function uses AccessProfiles to determine how to identify the +target requesting the credentials, which credentials in the user's Wallet match the target, and how +to provide the user's credentials to the target. If the target is an application, the AccessProfile +specifies the executable path and file name, and the TOE uses these values to create a key, called +an AccessProfile key, which is used to access the credentials in the user's Wallet. If the target uses +GUI widgets, the AccessProfile specifies the GUI widgets, and the TOE uses the GUI widget values +to create a key which is used to access the credentials in the user's Wallet. In addition, AccessProfiles +can optionally specify workflow automation for use where complicated workflow is required. +AccessProfiles are created and modified outside of the TOE using AccessStudio which is part of the +Operational Environment. The IMS Configuration Utility is used to add new AccessProfiles to the +IMS Server and to modify existing AccessProfiles that are used by the IMS Server. +Only the AccessAgent enforces the Wallet Access Control Policy defined by FDP_ACC.2 and +FDP_ACF.1. The IMS Server and other TOE components provide only a supporting role for this policy. +This section maps to the following SFR(s): +● FDP_ACC.2 +Page 41 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + ● FDP_ACF.1 +● FMT_MSA.1 +● FMT_MSA.3 +7.1.4 Security management +The TOE supports security function management mechanisms. This section describes the supported +mechanisms. +Role-based access control is used to protect access to operations in the AccessAdmin and +AccessAssistant applications. +Users are classified into three roles: +● Administrator +● Help desk +● User +The Administrator role is the most powerful of all the roles. The Help desk role is more powerful +than the User role, but less powerful than the Administrator role. The User role is the least powerful +of the roles and is intended for ordinary users. +A new user is granted the User role by default when they first sign-up. +The initial Administrator user account is created during the IMS Server's configuration, using the +IMS Web Configurator. Subsequently, an Administrator user can promote (i.e., modify the role of) +any user to Administrator or Help desk role through the AccessAdmin interface. +Only users with Administrator role will have full access to the AccessAdmin application. For example, +only Administrative users can modify machine policies and system policies. They can also view +machine policies and system policies, and view and modify user policies. +The Help desk role provides some of the capabilities of the Administrator role. The Help desk role +can view and modify user policies and view system policies and machine policies. +The TOE roles are stored in the IMS Server DB tables and managed by the AccessAdmin/IMS +application. Access control (based on these roles) to the IMS Server's various services is enforced +by the IMS Server. +The TOE contains several types of access policies that are used as configuration data by the TOE. +These access policies are grouped into the following major categories: +● Machine policies +● System policies +● User policies +Machine policies are policies that affect a specific machine or computer. Policies in this category +include the audit logging policies, desktop inactivity policies, and some of the Wallet-related policies +such as limiting the number of Wallets allowed on a machine and only allowing the Wallet to be +used on the machine where it was created. +System policies are policies that are applicable to all users and machines. Policies in this category +include auditing policies, password strength policies, and some of the Wallet-related policies. +User policies are policies that affect a specific user. Policies in this category include the Log on/Log +off policies and some of the Wallet-related policies such as the option for displaying of application +passwords in AccessAgent. +Page 42 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + This section maps to the following SFR(s): +● FMT_MTD.1 +● FMT_SMF.1 +● FMT_SMR.1 +Page 43 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + 8 Abbreviations, Terminology and References +8.1 Abbreviations +AA +AccessAgent +AD +Active Directory +AES +Advanced Encryption Standard +API +Application Programming Interface +CBC +Cipher Block Chaining +CSK +Common Symmetric Key +E-SSO +Enterprise Single Sign-On +GINA +Graphical Identification and Authentication +GSKit +IBM Global Security Toolkit +GUI +Graphical User Interface +HTTPS +Hypertext Transfer Protocol Secure +IMS +Integrated Management System +ISAM +IBM Security Access Manager +LDAP +Lightweight Directory Access Protocol +MAC +Mobile ActiveCode +OTP +One-Time Password +RADIUS +Remote Authentication Dial In User Service +RFID +Radio Frequency Identification +SFP +Security Function Policy +Page 44 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + SFR +Security Functional Requirement +SOAP +Originally defined as Simple Object Access Protocol +SPI +Service Provider Interface +SSL +Secure Sockets Layer +SSO +Single Sign-On +ST +Security Target +TCP/IP +Transmission Control Protocol / Internet Protocol +TLS +Transport Layer Security +TOE +Target of Evaluation +TSF +TOE Security Functionality +UI +User Interface +USB +Universal Serial Bus +WAS +WebSphere Application Server +XML +Extensible Markup Language +8.2 Terminology +This section contains definitions of technical terms that are used with a meaning specific to this +document. Terms defined in the [CC] are not reiterated here, unless stated otherwise. +AccessAgent +Client software that captures the user's credentials and acts on the user's behalf for single +sign-on and sign-off. +Authentication Factors +Different methods for authenticating to the product, such as USB keys, biometrics, proximity +cards, and passwords. See section 1.5.3.3 for the authentication factors supported in the +evaluated configuration. +GINA-less mode +Defines the mode where the IBM Security Access Manager for Enterprise Single Sign-On (ISAM +E-SSO) GINA is not installed on the operating system. +Page 45 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + GINA mode +Defines the mode where the IBM Security Access Manager for Enterprise Single Sign-On (ISAM +E-SSO) GINA is installed and used by the operating system. +GUI Widget +See Target Widget. +IMS Server +Provides centralized management of all users and policies. All policies are defined centrally and +enforced through AccessAgent. The IMS Server also provides comprehensive back-up of +credentials, loss management, audit, and compliance reporting. +Target Widget +A GUI widget belonging to an application monitored by the AccessAgent. The widget is monitored +by the TOE and filled in with information from the user's Wallet when applicable. For example, +a monitored application maintains a GUI widget referenced with "password" used to provide a +password to log into the application. The AccessAgent monitors the application for that +"password" widget in particular. If this widget is displayed, the AccessAgent detects the widget +and fills in the password information for the monitored application from the user's Wallet. +User +Humans or machines interacting with the TOE via the provided user and programmatic interfaces. +The term user in this document includes administrators of the TOE unless a specific distinction +is made in the text. +Wallet +A personal, encrypted repository of user credentials. The Wallet roams to the point of access +and stores the user's personal identity profiles, including log-in credentials, certificates, +encryption keys, and user policies. +8.3 References +Common Criteria for Information Technology Security Evaluation +CC +3.1R3 +Version +July 2009 +Date +http://www.commoncriteriaportal.org/files/ccfiles/CC +PART1V3.1R3.pdf +Location +http://www.commoncriteriaportal.org/files/ccfiles/CC +PART2V3.1R3.pdf +Location +http://www.commoncriteriaportal.org/files/ccfiles/CC +PART3V3.1R3.pdf +Location +Page 46 of 46 +Version: 1.19 +Copyright © 2009 - 2014 by atsec information security and IBM +Last update: 2014-03-05 +International Business Machines, Corporation +IBM Security Access Manager for Enterprise Single +Sign-On Version 8.2 with IMS Server Interim Fix 4 and +AccessAgent Fix Pack 22 Security Target + \ No newline at end of file diff --git a/tests/data/cc/analysis/reference_dataset.json b/tests/data/cc/analysis/reference_dataset.json index 38fb7fd0..04be80ca 100644 --- a/tests/data/cc/analysis/reference_dataset.json +++ b/tests/data/cc/analysis/reference_dataset.json @@ -15,7 +15,7 @@ "certs": [ { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "c30de3192d2e8ec2", + "dgst": "3129688580711e08", "status": "archived", "category": "Other Devices and Systems", "name": "Océ Digital Access Controller (DAC) R10.1.5 for use in the Océ VarioPrint 1055, 1055 BC, 1055 DP, 1065, 1075, 2062, 2075, 2075 DP printer/copier/scanner products", @@ -583,7 +583,7 @@ }, { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "53fe111411edfa45", + "dgst": "2c47b65953dcffb3", "status": "archived", "category": "Other Devices and Systems", "name": "Océ Digital Access Controller (DAC) R9.1.6", @@ -1229,7 +1229,7 @@ }, { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "692e91451741ef49", + "dgst": "d1b238729b25d745", "status": "archived", "category": "Other Devices and Systems", "name": "Océ Digital Access Controller R8.1.10", diff --git a/tests/data/cc/analysis/transitive_vulnerability_dataset.json b/tests/data/cc/analysis/transitive_vulnerability_dataset.json index abd4c7a3..5f052c11 100644 --- a/tests/data/cc/analysis/transitive_vulnerability_dataset.json +++ b/tests/data/cc/analysis/transitive_vulnerability_dataset.json @@ -15,7 +15,7 @@ "certs": [ { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "d0705c9e6fbaeba3", + "dgst": "11f77cb31b931a57", "status": "active", "category": "Operating Systems", "name": "IBM z/OS Version 2 Release 1", @@ -1339,7 +1339,7 @@ }, { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "011796336c7b94de", + "dgst": "487cf9415b61b49f", "status": "archived", "category": "Operating Systems", "name": "RACF Element of z/OS Version 2, Release 1", @@ -2288,7 +2288,7 @@ }, { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "ebc77980250ee68f", + "dgst": "c310425745136fdd", "status": "active", "category": "Operating Systems", "name": "IBM z/OS Version 2 Release 2", diff --git a/tests/data/cc/analysis/vulnerable_dataset.json b/tests/data/cc/analysis/vulnerable_dataset.json index 7978cb5a..cbabe14d 100644 --- a/tests/data/cc/analysis/vulnerable_dataset.json +++ b/tests/data/cc/analysis/vulnerable_dataset.json @@ -16,7 +16,7 @@ "certs": [ { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "ebd276cca70fd723", + "dgst": "ed91ff3e658457fd", "status": "active", "category": "Access Control Devices and Systems", "name": "IBM Security Access Manager for Enterprise Single Sign-On Version 8.2", @@ -97,7 +97,7 @@ }, { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "37e1b22e5933b0ed", + "dgst": "95e3850bef32f410", "status": "active", "category": "Access Control Devices and Systems", "name": "IBM WebSphere Application Server (WAS) 7.0", diff --git a/tests/data/cc/certificate/fictional_cert.json b/tests/data/cc/certificate/fictional_cert.json index 54781dd5..32475e69 100644 --- a/tests/data/cc/certificate/fictional_cert.json +++ b/tests/data/cc/certificate/fictional_cert.json @@ -1,6 +1,6 @@ { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "a9ccb81a92e547dc", + "dgst": "8049938203b26f7b", "status": "archived", "category": "Sample category", "name": "Sample certificate name", diff --git a/tests/data/cc/dataset/auxiliary_datasets/maintenances/maintenance_updates.json b/tests/data/cc/dataset/auxiliary_datasets/maintenances/maintenance_updates.json index 5596b597..38c3db5b 100644 --- a/tests/data/cc/dataset/auxiliary_datasets/maintenances/maintenance_updates.json +++ b/tests/data/cc/dataset/auxiliary_datasets/maintenances/maintenance_updates.json @@ -16,7 +16,7 @@ "certs": [ { "_type": "sec_certs.sample.cc_maintenance_update.CCMaintenanceUpdate", - "dgst": "cert_8a5e6bcda602920c_update_559ed93dd80320b5", + "dgst": "cert_8f08cacb49a742fb_update_559ed93dd80320b5", "name": "Fortinet FortiGate w/ FortiOS v5.6.7 Build 6022", "report_link": "https://www.commoncriteriaportal.org/files/epfiles/383-7-159%20MR%20v1.0e.pdf", "st_link": "https://www.commoncriteriaportal.org/files/epfiles/383-7-159%20ST%20v1.4%20CCRA.pdf", @@ -93,7 +93,7 @@ "indirect_transitive_cves": null, "scheme_data": null }, - "related_cert_digest": "8a5e6bcda602920c", + "related_cert_digest": "8f08cacb49a742fb", "maintenance_date": "2019-08-26" } ] diff --git a/tests/data/cc/dataset/report_309ac2fd7f2dcf17.txt b/tests/data/cc/dataset/report_309ac2fd7f2dcf17.txt deleted file mode 100644 index 46bff446..00000000 --- a/tests/data/cc/dataset/report_309ac2fd7f2dcf17.txt +++ /dev/null @@ -1,481 +0,0 @@ -Ärendetyp: 6 Diarienummer: 18FMV7705-43:1 -HEMLIG/ -enligt Offentlighets- och sekretesslagen -(2009:400) -2020-06-15 -Country of origin: Sweden -Försvarets materielverk -Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -Issue: 1.0, 2020-Jun-15 -Authorisation: Helén Svensson, Lead Certifier , CSEC - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -2 (18) -Table of Contents -1 Executive Summary 3 -2 Identification 5 -3 Security Policy 6 -3.1 Security Management 6 -3.2 Security Audit 6 -3.3 Identification and Authentication 6 -3.4 User Data Protection 7 -3.5 Trusted Path / Channel 7 -3.6 Cryptographic Support 7 -4 Assumptions and Clarification of Scope 8 -4.1 Usage Assumptions 8 -4.2 Environmental Assumptions 8 -4.3 Clarification of Scope 8 -5 Architectural Information 9 -6 Documentation 11 -7 IT Product Testing 12 -7.1 Developer Testing 12 -7.2 Evaluator Testing 12 -7.3 Penetration Testing 12 -8 Evaluated Configuration 13 -9 Results of the Evaluation 14 -10 Evaluator Comments and Recommendations 15 -11 Glossary 16 -12 Bibliography 17 -Appendix A Scheme Versions 18 -A.1 Scheme/Quality Management System 18 -A.2 Scheme Notes 18 - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -3 (18) -1 Executive Summary -The TOE is NetIQ Identity Manager 4.7. -It is a software TOE consisting of the components listed below that can be setup on -separate hardware platforms, see the [ST], or as a virtual appliances. -TOE Components: - Identity Applications (RBPM) 4.7.3.0.1109 - Identity Manager Engine 4.7.3.0.AE - Identity Reporting Module 6.5.0. F14508F - Sentinel Log Management for Identity Governance and Administration -8.2.2.0_5415 - One SSO Provider (OSP) 6.3.3.0 - Self Service Password Reset (SSPR) 4.4.0.2 B366 r39762 -The TOE is delivered as software with documentation and can be installed in a physi- -cal or virtual environment. -It is important to verify the integrity of the TOE for secure acceptance of the TOE in -accordance with the preparative procedures of the guidance, i.e. verify the TLS con- -nection, the CA certificate and the file hash. It is also important to update the TOE (in- -cluding 3rd party software) and the operational environment of the TOE in accordance -with the preparative procedures of the guidance to mitigate known vulnerabilities. -No conformance claims to any PP are made for the TOE. -The evaluation has been performed by Combitech AB in Växjö, Sweden and by -EWA-Canada in Ottawa, Canada. Site Visit and parts of the testing was performed at -the developer’s site in Bangalore, India. -The evaluation was completed on 2020-06-02. The evaluation was conducted in ac- -cordance with the requirements of Common Criteria, version 3.1 R5. -Combitech AB is a licensed evaluation facility for Common Criteria under the Swe- -dish Common Criteria Evaluation and Certification Scheme. Combitech AB is also -accredited by the Swedish accreditation body SWEDAC according to ISO/IEC 17025 -for Common Criteria evaluation. EWA-Canada Ltd. operates as a Foreign location for -Combitech AB within scope of the Swedish Common Criteria Evaluation and Certifi- -cation Scheme. -The certifier monitored the activities of the evaluator by reviewing all successive ver- -sions of the evaluation reports, and by observing site-visit and testing. The certifier -determined that the evaluation results confirm the security claims in the Security -Target (ST) and the Common Methodology for evaluation assurance level EAL3 -augmented by ALC_FLR.2 -The certification results only apply to the version of the product indicated in the -certificate, and on the condition that all the stipulations in the Security Target are -met. -This certificate is not an endorsement of the IT product by CSEC or any other or- -ganisation that recognises or gives effect to this certificate, and no warranty of the -IT product by CSEC or any other organisation that recognises or gives effect to this -certificate is either expressed or implied. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -4 (18) -As specified in the security target of this evaluation, the invocation of cryptographic -primitives has been included in the TOE, while the implementation of these primi- -tives has been located in TOE environment. Therefore the invocation of crypto- -graphic primitives has been in the scope of this evaluation, while correctness of im- -plementation of cryptographic primitives been excluded from the TOE. Correctness -of implementation is done through third party certification Cryptographic Module -Validation Program (CMVP) certificate number 1747 referred to in the Security -Target. -Users of this product are advised to consider their acceptance of this third party af- -firmation regarding the correctness of implementation of the cryptographic primi- -tives. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -5 (18) -2 Identification -Certification Identification -Certification ID CSEC2018013 -Name and version of the cer- -tified IT product -NetIQ® Identity Manager 4.7 -TOE components: - Identity Applications (RBPM) 4.7.3.0.1109 - Identity Manager Engine 4.7.3.0.AE - Identity Reporting Module 6.5.0. F14508F - Sentinel Log Management for Identity Govern- -ance and Administration 8.2.2.0_5415 - One SSO Provider (OSP) 6.3.3.0 - Self Service Password Reset (SSPR) 4.4.0.2 -B366 r39762 -Security Target Identification NetIQ Identity Manager 4.7 Security Target (ST), -NetIQ Corporation , 2020-06-01, document version -2.6 -EAL EAL3 + ALC_FLR.2 -Sponsor NetIQ Corporation -Developer NetIQ Corporation -ITSEF Combitech AB and EWA-Canada -Common Criteria version 3.1 release 5 -CEM version 3.1 release 5 -QMS version 1.23.2 -Scheme Notes Release 15.0 -Recognition Scope CCRA, SOGIS and EA/MLA -Certification date 2020-06-15 - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -6 (18) -3 Security Policy -The security features performed by the TOE are as follows: - Security Management - Security Audit - Identification and Authentication - User Data Protection - Trusted Path / Channels - Cryptographic Support -3.1 Security Management -The TOE maintains operator roles. The individual roles are categorized into two main -roles: the Administrator and the User. -Administrator - A user who has rights to configure and manage all aspects of the TOE -User - The user’s capabilities can be configured to: - View hierarchical relationships between User objects - View and edit user information (with appropriate rights). - Search for users or resources using advanced search criteria (which can be saved -for later reuse). - Recover forgotten passwords. -Only an Administrator can determine the behavior of, disable, enable, and modify the -behavior of the functions that implement the Discretionary Access Control SFP. The -TPE ensures only secure values are accepted for the security attributes listed with Dis- -cretionary Access Control SFP. -3.2 Security Audit -The TOE generates the following audit data: - Start-up and shutdown of the audit functions (instantiated by startup of the TOE) - User login/logout - Login failures -The TOE provides the Administrator with the capability to read all audit data gener- -ated within the TOE via the console. The GUI provides a suitable means for an Ad- -ministrator to interpret the information from the audit log. -The A.TIMESOURCE is added to the assumptions on operational environment, and -OE.TIME is added to the operational environment security objectives. The time and -date provided by the operational environment are used to form the timestamps. The -TOE ensures that the audit trail data is stamped when recorded with a dependable date -and time received from the OE (operating system). In this manner, accurate time and -date is maintained on the TOE. -3.3 Identification and Authentication -The IDM console application provides user interfaces that administrators may use to -manage TOE functions. The operating system and the database in the TOE Environ- -ment are queried to individually authenticate administrators or users. The TOE main- -tains authorization information that determines which TOE functions an authenticated -administrators or users (of a given role) may perform. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -7 (18) -The TOE maintains the following list of security attributes belonging to individual us- -ers: - User Identity (i.e., user name) - Authentication Status (whether the IT Environment validated the username/pass- -word) - Privilege Level (Administrator or User) -3.4 User Data Protection -The TOE implements a discretionary access control policy to define what roles can -access particular functions of the TOE. All access and actions for system reports, com- -ponent audit logs, TOE configuration, operator account attributes (defined in -FIA_ATD.1) are protected via access control list. When a user requests to perform an -action on an object, the TOE verifies the role associated with the user name. Access is -granted if the user (or group of users) has the specific rights required for the type of -operation requested on the object. -Identity Manager can enforce password policies on incoming passwords from con- -nected systems and on passwords set or changed through the User Application pass- -word self-service. If the new password does not comply, you can specify that Identity -Manager not accept the password. This also means that passwords that don't comply -with your policies are not distributed to other connected systems. -In addition, can enforce password policies on connected systems. If the password be- -ing published to the Identity Vault does not comply with rules in a policy, you can -specify that Identity Manager not only does not accept the password for distribution, -but actually resets the noncompliant password on the connected system by using the -current Distribution password in the Identity Vault. -3.5 Trusted Path / Channel -The TOE provides a trusted channel between the TOE and external web servers. -The TOE provides a trusted path for TOE administrators and TOE users to communi- -cate with the TOE. The trusted path is implemented using HTTPS. The TOE’s imple- -mentation of TLS is described in the previous section (Trusted Channel). -3.6 Cryptographic Support -Cryptographic protection of data in transit between the TOE and remote users, and be- -tween the TOE and external web servers is provided by the OpenSSL FIPS Object -Module software version 2.0.10 (Cryptographic Module Validation Program (CMVP) -certificate number 1747) libraries. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -8 (18) -4 Assumptions and Clarification of Scope -4.1 Usage Assumptions -The Security Target [ST] makes two assumptions on the usage of the TOE. -A.MANAGE - Administrators of the TOE are assumed to be appropriately trained to -undertake the installation, configuration and management of the TOE in a secure and -trusted manner. -A.NOEVIL - Administrators of the TOE and users on the local area network are not -careless, willfully negligent, nor hostile, and will follow and abide by the instructions -provided by the TOE documentation -4.2 Environmental Assumptions -The Security Target [ST] makes three assumptions on the operational environment of -the TOE. -A.LOCATE - The processing platforms on which the TOE resides are assumed to be -located within a facility that provides controlled access -A.CONFIG - The TOE is configured to receive all passwords and associated data from -network-attached systems. -A.TIMESOURCE - The TOE has a trusted source for system time via NTP server -4.3 Clarification of Scope -The Security Target contains five threats, which have been considered during the eval- -uation. -T.NO_AUTH - An unauthorized user may gain access to the TOE and alter the TOE -configuration. -T.NO_PRIV - An authorized user of the TOE exceeds his/her assigned security privi- -leges resulting in unauthorized modification of the TOE configuration and/or data. -T.USER_ACCESS_DENY - An authorized user may be able to change user authenti- -cation data and or user access policies and deny their access to it later. -T.PASSWD_COMPROMISE - An unauthorized user may be able to obtain and use -user passwords. -T.PROT_TRANS - An unauthorized user may be able to gather information from -communications between components. -The Security Target contains one Organisational Security Policies (OSPs), which have -been considered during the evaluation. -P.REMOTE_DATA - Passwords and account information from network-attached sys- -tems shall be monitored and managed. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -9 (18) -5 Architectural Information -The TOE consists of the following components: - Administration Workstation (Console)2 - Identity Applications (RBPM) - Designer aka Identity Manager Designer - Analyzer aka Identity Manager Analyzer - Identity Manager - Identity Manager Engine - Identity Vault - iManager - Reporting Server - Identity Reporting Module - Log Manager - Sentinel Log Management for Identity Governance and Administration - SSO Provider - One SSO Provider (OSP) - Self Service Password Reset - Self Service Password Reset (SSPR) -Figure 1, TOE Deployment with subsystems -The TOE provides the following functions: data synchronization, role management, -auditing/reporting, and management. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -10 (18) - Data synchronization, including password synchronization, is provided by the -base components of the Identity Manager solution: the Identity Vault, Identity -Manager engine, drivers, Remote Loader, and connected applications - Role management is provided by the User Application - Auditing and reporting are provided by the Identity Reporting Module - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -11 (18) -6 Documentation -The TOE includes the following guidance documentation: - Quick Start Guide for Installing NetIQ Identity Manager 4.7 February 2018 -[QSIM] - NetIQ Identity Manager Setup Guide for Linux February 2018 [SUL] - NetIQ Identity Manager 4.7, Operational User Guidance and Preparative Proce- -dures Supplement (AGD-IGS), version 0.6, is supplied for those customers that -need guidance on how to set the TOE in the evaluated configuration. [AGD] - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -12 (18) -7 IT Product Testing -7.1 Developer Testing -There are 30 test cases covering all SFRs with at least one test per SFR. All tests were -successful with a pass verdict. -7.2 Evaluator Testing -Since all SFRs and security function requirements were tested by the developer the -evaluator focused on repetition of the developer’s test cases and penetration testing. -7.3 Penetration Testing -Port and vulnerability scan were performed on Identity manager engine, Identity appli- -cations (RBPM), and Identity reporting module. -No unforeseen ports or vulnerabilities were found. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -13 (18) -8 Evaluated Configuration -The TOE consists of a set of software applications run on one or multiple distributed -systems. The TOE requires the following software components as part of the evalu- -ated configuration: -Component Requirements -Administration Workstation Mozilla Firefox 65 -Identity Applications (RBPM) -Designer / Analyzer) -SUSE Linux Enterprise Server 12 SP4 -Identity Manager (Identity Man- -ager Engine) -SUSE Linux Enterprise Server 12 SP4 -Reporting Server (Identity Re- -porting Module) -SUSE Linux Enterprise Server 12 SP4 -Log Manager (Sentinel Log Man- -agement for Identity Governance -and Administration) -SUSE Linux Enterprise Server 12 SP4 -SSO Provider (OneSSO Provider) SUSE Linux Enterprise Server 12 SP4 -Self Service Password Reset SUSE Linux Enterprise Server 12 SP4 -In addition to the platform requirements mentioned above, the following hardware re- -sources are needed in order to install and configure Identity Manager on each plat- -form: - A minimum of 8 GB RAM - 15 GB available disk space to install all the components. - Additional disk space to configure and populate data. This might vary depending -on your connected systems and number of objects in the Identity Vault. -For server-based components, it is recommended that the platform have a minimum of -2 CPUs or cores. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -14 (18) -9 Results of the Evaluation -The evaluators applied each work unit of the Common Methodology [CEM] within -the scope of the evaluation, and concluded that the TOE meets the security objectives -stated in the Security Target [ST] for an attack potential of Basic. -The certifier reviewed the work of the evaluators and determined that the evaluation -was conducted in accordance with the Common Criteria [CC]. -The evaluators' overall verdict is PASS. -The verdicts for the respective assurance classes and components are summarised in -the following table: -Assurance Class/Family Short name Verdict -Development ADV: PASS -Security architecture description ADV_ARC.1 PASS -Functional specification with complete summary ADV_FSP.3 PASS -Architectural design ADV_TDS.2 PASS -Guidance documents AGD: PASS -Operational user guidance AGD_OPE.1 PASS -Preparative procedures AGD_PRE.1 PASS -Life-cycle support ALC: PASS -Authorisation controls ALC_CMC.3 PASS -Implementation representation CM coverage ALC_CMS.3 PASS -Delivery procedures ALC_DEL.1 PASS -Identification of security measures ALC_DVS.1 PASS -Developer defined life-cycle model ALC_LCD.1 PASS -Flaw reporting procedures ALC_FLR.2 PASS -Security Target evaluation ASE: PASS -Conformance claims ASE_CCL.1 PASS -Extended components definition ASE_ECD.1 PASS -ST introduction ASE_INT.1 PASS -Security objectives ASE_OBJ.2 PASS -Derived security requirements ASE_REQ.2 PASS -Security problem definition ASE_SPD.1 PASS -TOE summary specification ASE_TSS.1 PASS -Tests ATE: PASS -Analysis of coverage ATE_COV.2 PASS -Testing: basic design ATE_DPT.1 PASS -Functional testing ATE_FUN.1 PASS -Independent testing - sample ATE_IND.2 PASS -Vulnerability assessment AVA: PASS -Vulnerability analysis AVA_VAN.2 PASS - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -15 (18) -10 Evaluator Comments and Recommendations -None. - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -16 (18) -11 Glossary -CC Common Criteria version 3.1 -EAL Evaluation Assurance Level -FIPS Federal Information Processing Standard -IDM Identity Manager -ITSEF -IT Security Evaluation Facility, test labora- -tory licensed to operate within a evaluation -and certification scheme -NTP Network Time Protocol -OSP Organizational Security Policy -OSP One SSO Provider -SSO Single Sign On -SFP Security Function Policy -SFR Security Functional Requirement -SSPR Self Service Password Reset -ST Security Target -TOE Target of Evaluation - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -17 (18) -12 Bibliography -ST NetIQ Identity Manager 4.7 Security Target (ST), NetIQ -Corporation, 2020-06-01, document version 2.6 -QSIM Quick Start Guide for Installing NetIQ Identity Manager 4.7 -February 2018 -SUL NetIQ Identity Manager Setup Guide for Linux February 2018 -AGD NetIQ Identity Manager 4.7, Operational User Guidance and -Preparative Procedures Supplement (AGD-IGS), version 0.6 -CCpart1 Common Criteria for Information Technology Security Evaluation, -Part 1, version 3.1 revision 5, CCMB-2017-04-001 -CCpart2 Common Criteria for Information Technology Security Evaluation, -Part 2, version 3.1 revision 5, CCMB-2017-04-002 -CCpart3 Common Criteria for Information Technology Security -Evaluation,Part 3, version 3.1 revision 5, CCMB-2017-04-003 -CC CCpart1 + CCpart2 + CCpart3 -CEM Common Methodology for Information Technology Security -Evaluation, version 3.1 revision 5, CCMB-2017-04-004 -SP-002 SP-002 Evaluation and Certification, CSEC, 2019-09-24, document -version 31.0 - Swedish Certification Body for IT Security -Certification Report NetIQ® Identity Manager 4.7 -18FMV7705-43:1 1.0 2020-06-15 -18 (18) -Appendix A Scheme Versions -During the certification the following versions of the Swedish Common Criteria Eval- -uation and Certification scheme have been used. -A.1 Scheme/Quality Management System -During the certification project, the following versions of the quality management sys- -tem (QMS) have been applicable since the certification application was received: -QMS 1.21.5 valid from 2018-11-19 -QMS 1.22 valid from 2019-02-01 -QMS 1.22.1 valid from 2019-03-08 -QMS 1.22.2 valid from 2019-05-02 -QMS 1.22.3 valid from 2019-05-20 -QMS 1.23 valid from 2019-10-14 -QMS 1.23.1 valid from 2020-03-06 -QMS 1.23.2 valid from 2020-05-11 -In order to ensure consistency in the outcome of the certification, the certifier has ex- -amined the changes introduced in each update of the quality management system. -The changes between consecutive versions are outlined in “Ändringslista CSEC QMS -1.23.1”. The certifier concluded that, from QMS 1.21.5 to the current QMS 1.23.2, -there are no changes with impact on the result of the certification. -Note that the SP-188 Scheme Crypto Policy version 9.0 was introduced in QMS 1.23. -The certification application was submitted before the SP-188 Scheme Crypto Policy -version 9.0 was introduced and therefore version 8.0 was used. -A.2 Scheme Notes -The following Scheme interpretations have been considered during the certification. - Scheme Note 15 - Demonstration of test Coverage - Scheme Note 18 - Highlighted Requirements on the Security Target - Scheme Note 22 - Vulnerability assessment - Scheme Note 28 - Updated procedures for application, evaluation and certification - \ No newline at end of file diff --git a/tests/data/cc/dataset/report_e3dcf91ef38ddbf0.txt b/tests/data/cc/dataset/report_e3dcf91ef38ddbf0.txt new file mode 100644 index 00000000..46bff446 --- /dev/null +++ b/tests/data/cc/dataset/report_e3dcf91ef38ddbf0.txt @@ -0,0 +1,481 @@ +Ärendetyp: 6 Diarienummer: 18FMV7705-43:1 +HEMLIG/ +enligt Offentlighets- och sekretesslagen +(2009:400) +2020-06-15 +Country of origin: Sweden +Försvarets materielverk +Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +Issue: 1.0, 2020-Jun-15 +Authorisation: Helén Svensson, Lead Certifier , CSEC + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +2 (18) +Table of Contents +1 Executive Summary 3 +2 Identification 5 +3 Security Policy 6 +3.1 Security Management 6 +3.2 Security Audit 6 +3.3 Identification and Authentication 6 +3.4 User Data Protection 7 +3.5 Trusted Path / Channel 7 +3.6 Cryptographic Support 7 +4 Assumptions and Clarification of Scope 8 +4.1 Usage Assumptions 8 +4.2 Environmental Assumptions 8 +4.3 Clarification of Scope 8 +5 Architectural Information 9 +6 Documentation 11 +7 IT Product Testing 12 +7.1 Developer Testing 12 +7.2 Evaluator Testing 12 +7.3 Penetration Testing 12 +8 Evaluated Configuration 13 +9 Results of the Evaluation 14 +10 Evaluator Comments and Recommendations 15 +11 Glossary 16 +12 Bibliography 17 +Appendix A Scheme Versions 18 +A.1 Scheme/Quality Management System 18 +A.2 Scheme Notes 18 + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +3 (18) +1 Executive Summary +The TOE is NetIQ Identity Manager 4.7. +It is a software TOE consisting of the components listed below that can be setup on +separate hardware platforms, see the [ST], or as a virtual appliances. +TOE Components: + Identity Applications (RBPM) 4.7.3.0.1109 + Identity Manager Engine 4.7.3.0.AE + Identity Reporting Module 6.5.0. F14508F + Sentinel Log Management for Identity Governance and Administration +8.2.2.0_5415 + One SSO Provider (OSP) 6.3.3.0 + Self Service Password Reset (SSPR) 4.4.0.2 B366 r39762 +The TOE is delivered as software with documentation and can be installed in a physi- +cal or virtual environment. +It is important to verify the integrity of the TOE for secure acceptance of the TOE in +accordance with the preparative procedures of the guidance, i.e. verify the TLS con- +nection, the CA certificate and the file hash. It is also important to update the TOE (in- +cluding 3rd party software) and the operational environment of the TOE in accordance +with the preparative procedures of the guidance to mitigate known vulnerabilities. +No conformance claims to any PP are made for the TOE. +The evaluation has been performed by Combitech AB in Växjö, Sweden and by +EWA-Canada in Ottawa, Canada. Site Visit and parts of the testing was performed at +the developer’s site in Bangalore, India. +The evaluation was completed on 2020-06-02. The evaluation was conducted in ac- +cordance with the requirements of Common Criteria, version 3.1 R5. +Combitech AB is a licensed evaluation facility for Common Criteria under the Swe- +dish Common Criteria Evaluation and Certification Scheme. Combitech AB is also +accredited by the Swedish accreditation body SWEDAC according to ISO/IEC 17025 +for Common Criteria evaluation. EWA-Canada Ltd. operates as a Foreign location for +Combitech AB within scope of the Swedish Common Criteria Evaluation and Certifi- +cation Scheme. +The certifier monitored the activities of the evaluator by reviewing all successive ver- +sions of the evaluation reports, and by observing site-visit and testing. The certifier +determined that the evaluation results confirm the security claims in the Security +Target (ST) and the Common Methodology for evaluation assurance level EAL3 +augmented by ALC_FLR.2 +The certification results only apply to the version of the product indicated in the +certificate, and on the condition that all the stipulations in the Security Target are +met. +This certificate is not an endorsement of the IT product by CSEC or any other or- +ganisation that recognises or gives effect to this certificate, and no warranty of the +IT product by CSEC or any other organisation that recognises or gives effect to this +certificate is either expressed or implied. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +4 (18) +As specified in the security target of this evaluation, the invocation of cryptographic +primitives has been included in the TOE, while the implementation of these primi- +tives has been located in TOE environment. Therefore the invocation of crypto- +graphic primitives has been in the scope of this evaluation, while correctness of im- +plementation of cryptographic primitives been excluded from the TOE. Correctness +of implementation is done through third party certification Cryptographic Module +Validation Program (CMVP) certificate number 1747 referred to in the Security +Target. +Users of this product are advised to consider their acceptance of this third party af- +firmation regarding the correctness of implementation of the cryptographic primi- +tives. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +5 (18) +2 Identification +Certification Identification +Certification ID CSEC2018013 +Name and version of the cer- +tified IT product +NetIQ® Identity Manager 4.7 +TOE components: + Identity Applications (RBPM) 4.7.3.0.1109 + Identity Manager Engine 4.7.3.0.AE + Identity Reporting Module 6.5.0. F14508F + Sentinel Log Management for Identity Govern- +ance and Administration 8.2.2.0_5415 + One SSO Provider (OSP) 6.3.3.0 + Self Service Password Reset (SSPR) 4.4.0.2 +B366 r39762 +Security Target Identification NetIQ Identity Manager 4.7 Security Target (ST), +NetIQ Corporation , 2020-06-01, document version +2.6 +EAL EAL3 + ALC_FLR.2 +Sponsor NetIQ Corporation +Developer NetIQ Corporation +ITSEF Combitech AB and EWA-Canada +Common Criteria version 3.1 release 5 +CEM version 3.1 release 5 +QMS version 1.23.2 +Scheme Notes Release 15.0 +Recognition Scope CCRA, SOGIS and EA/MLA +Certification date 2020-06-15 + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +6 (18) +3 Security Policy +The security features performed by the TOE are as follows: + Security Management + Security Audit + Identification and Authentication + User Data Protection + Trusted Path / Channels + Cryptographic Support +3.1 Security Management +The TOE maintains operator roles. The individual roles are categorized into two main +roles: the Administrator and the User. +Administrator - A user who has rights to configure and manage all aspects of the TOE +User - The user’s capabilities can be configured to: + View hierarchical relationships between User objects + View and edit user information (with appropriate rights). + Search for users or resources using advanced search criteria (which can be saved +for later reuse). + Recover forgotten passwords. +Only an Administrator can determine the behavior of, disable, enable, and modify the +behavior of the functions that implement the Discretionary Access Control SFP. The +TPE ensures only secure values are accepted for the security attributes listed with Dis- +cretionary Access Control SFP. +3.2 Security Audit +The TOE generates the following audit data: + Start-up and shutdown of the audit functions (instantiated by startup of the TOE) + User login/logout + Login failures +The TOE provides the Administrator with the capability to read all audit data gener- +ated within the TOE via the console. The GUI provides a suitable means for an Ad- +ministrator to interpret the information from the audit log. +The A.TIMESOURCE is added to the assumptions on operational environment, and +OE.TIME is added to the operational environment security objectives. The time and +date provided by the operational environment are used to form the timestamps. The +TOE ensures that the audit trail data is stamped when recorded with a dependable date +and time received from the OE (operating system). In this manner, accurate time and +date is maintained on the TOE. +3.3 Identification and Authentication +The IDM console application provides user interfaces that administrators may use to +manage TOE functions. The operating system and the database in the TOE Environ- +ment are queried to individually authenticate administrators or users. The TOE main- +tains authorization information that determines which TOE functions an authenticated +administrators or users (of a given role) may perform. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +7 (18) +The TOE maintains the following list of security attributes belonging to individual us- +ers: + User Identity (i.e., user name) + Authentication Status (whether the IT Environment validated the username/pass- +word) + Privilege Level (Administrator or User) +3.4 User Data Protection +The TOE implements a discretionary access control policy to define what roles can +access particular functions of the TOE. All access and actions for system reports, com- +ponent audit logs, TOE configuration, operator account attributes (defined in +FIA_ATD.1) are protected via access control list. When a user requests to perform an +action on an object, the TOE verifies the role associated with the user name. Access is +granted if the user (or group of users) has the specific rights required for the type of +operation requested on the object. +Identity Manager can enforce password policies on incoming passwords from con- +nected systems and on passwords set or changed through the User Application pass- +word self-service. If the new password does not comply, you can specify that Identity +Manager not accept the password. This also means that passwords that don't comply +with your policies are not distributed to other connected systems. +In addition, can enforce password policies on connected systems. If the password be- +ing published to the Identity Vault does not comply with rules in a policy, you can +specify that Identity Manager not only does not accept the password for distribution, +but actually resets the noncompliant password on the connected system by using the +current Distribution password in the Identity Vault. +3.5 Trusted Path / Channel +The TOE provides a trusted channel between the TOE and external web servers. +The TOE provides a trusted path for TOE administrators and TOE users to communi- +cate with the TOE. The trusted path is implemented using HTTPS. The TOE’s imple- +mentation of TLS is described in the previous section (Trusted Channel). +3.6 Cryptographic Support +Cryptographic protection of data in transit between the TOE and remote users, and be- +tween the TOE and external web servers is provided by the OpenSSL FIPS Object +Module software version 2.0.10 (Cryptographic Module Validation Program (CMVP) +certificate number 1747) libraries. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +8 (18) +4 Assumptions and Clarification of Scope +4.1 Usage Assumptions +The Security Target [ST] makes two assumptions on the usage of the TOE. +A.MANAGE - Administrators of the TOE are assumed to be appropriately trained to +undertake the installation, configuration and management of the TOE in a secure and +trusted manner. +A.NOEVIL - Administrators of the TOE and users on the local area network are not +careless, willfully negligent, nor hostile, and will follow and abide by the instructions +provided by the TOE documentation +4.2 Environmental Assumptions +The Security Target [ST] makes three assumptions on the operational environment of +the TOE. +A.LOCATE - The processing platforms on which the TOE resides are assumed to be +located within a facility that provides controlled access +A.CONFIG - The TOE is configured to receive all passwords and associated data from +network-attached systems. +A.TIMESOURCE - The TOE has a trusted source for system time via NTP server +4.3 Clarification of Scope +The Security Target contains five threats, which have been considered during the eval- +uation. +T.NO_AUTH - An unauthorized user may gain access to the TOE and alter the TOE +configuration. +T.NO_PRIV - An authorized user of the TOE exceeds his/her assigned security privi- +leges resulting in unauthorized modification of the TOE configuration and/or data. +T.USER_ACCESS_DENY - An authorized user may be able to change user authenti- +cation data and or user access policies and deny their access to it later. +T.PASSWD_COMPROMISE - An unauthorized user may be able to obtain and use +user passwords. +T.PROT_TRANS - An unauthorized user may be able to gather information from +communications between components. +The Security Target contains one Organisational Security Policies (OSPs), which have +been considered during the evaluation. +P.REMOTE_DATA - Passwords and account information from network-attached sys- +tems shall be monitored and managed. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +9 (18) +5 Architectural Information +The TOE consists of the following components: + Administration Workstation (Console)2 + Identity Applications (RBPM) + Designer aka Identity Manager Designer + Analyzer aka Identity Manager Analyzer + Identity Manager + Identity Manager Engine + Identity Vault + iManager + Reporting Server + Identity Reporting Module + Log Manager + Sentinel Log Management for Identity Governance and Administration + SSO Provider + One SSO Provider (OSP) + Self Service Password Reset + Self Service Password Reset (SSPR) +Figure 1, TOE Deployment with subsystems +The TOE provides the following functions: data synchronization, role management, +auditing/reporting, and management. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +10 (18) + Data synchronization, including password synchronization, is provided by the +base components of the Identity Manager solution: the Identity Vault, Identity +Manager engine, drivers, Remote Loader, and connected applications + Role management is provided by the User Application + Auditing and reporting are provided by the Identity Reporting Module + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +11 (18) +6 Documentation +The TOE includes the following guidance documentation: + Quick Start Guide for Installing NetIQ Identity Manager 4.7 February 2018 +[QSIM] + NetIQ Identity Manager Setup Guide for Linux February 2018 [SUL] + NetIQ Identity Manager 4.7, Operational User Guidance and Preparative Proce- +dures Supplement (AGD-IGS), version 0.6, is supplied for those customers that +need guidance on how to set the TOE in the evaluated configuration. [AGD] + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +12 (18) +7 IT Product Testing +7.1 Developer Testing +There are 30 test cases covering all SFRs with at least one test per SFR. All tests were +successful with a pass verdict. +7.2 Evaluator Testing +Since all SFRs and security function requirements were tested by the developer the +evaluator focused on repetition of the developer’s test cases and penetration testing. +7.3 Penetration Testing +Port and vulnerability scan were performed on Identity manager engine, Identity appli- +cations (RBPM), and Identity reporting module. +No unforeseen ports or vulnerabilities were found. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +13 (18) +8 Evaluated Configuration +The TOE consists of a set of software applications run on one or multiple distributed +systems. The TOE requires the following software components as part of the evalu- +ated configuration: +Component Requirements +Administration Workstation Mozilla Firefox 65 +Identity Applications (RBPM) +Designer / Analyzer) +SUSE Linux Enterprise Server 12 SP4 +Identity Manager (Identity Man- +ager Engine) +SUSE Linux Enterprise Server 12 SP4 +Reporting Server (Identity Re- +porting Module) +SUSE Linux Enterprise Server 12 SP4 +Log Manager (Sentinel Log Man- +agement for Identity Governance +and Administration) +SUSE Linux Enterprise Server 12 SP4 +SSO Provider (OneSSO Provider) SUSE Linux Enterprise Server 12 SP4 +Self Service Password Reset SUSE Linux Enterprise Server 12 SP4 +In addition to the platform requirements mentioned above, the following hardware re- +sources are needed in order to install and configure Identity Manager on each plat- +form: + A minimum of 8 GB RAM + 15 GB available disk space to install all the components. + Additional disk space to configure and populate data. This might vary depending +on your connected systems and number of objects in the Identity Vault. +For server-based components, it is recommended that the platform have a minimum of +2 CPUs or cores. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +14 (18) +9 Results of the Evaluation +The evaluators applied each work unit of the Common Methodology [CEM] within +the scope of the evaluation, and concluded that the TOE meets the security objectives +stated in the Security Target [ST] for an attack potential of Basic. +The certifier reviewed the work of the evaluators and determined that the evaluation +was conducted in accordance with the Common Criteria [CC]. +The evaluators' overall verdict is PASS. +The verdicts for the respective assurance classes and components are summarised in +the following table: +Assurance Class/Family Short name Verdict +Development ADV: PASS +Security architecture description ADV_ARC.1 PASS +Functional specification with complete summary ADV_FSP.3 PASS +Architectural design ADV_TDS.2 PASS +Guidance documents AGD: PASS +Operational user guidance AGD_OPE.1 PASS +Preparative procedures AGD_PRE.1 PASS +Life-cycle support ALC: PASS +Authorisation controls ALC_CMC.3 PASS +Implementation representation CM coverage ALC_CMS.3 PASS +Delivery procedures ALC_DEL.1 PASS +Identification of security measures ALC_DVS.1 PASS +Developer defined life-cycle model ALC_LCD.1 PASS +Flaw reporting procedures ALC_FLR.2 PASS +Security Target evaluation ASE: PASS +Conformance claims ASE_CCL.1 PASS +Extended components definition ASE_ECD.1 PASS +ST introduction ASE_INT.1 PASS +Security objectives ASE_OBJ.2 PASS +Derived security requirements ASE_REQ.2 PASS +Security problem definition ASE_SPD.1 PASS +TOE summary specification ASE_TSS.1 PASS +Tests ATE: PASS +Analysis of coverage ATE_COV.2 PASS +Testing: basic design ATE_DPT.1 PASS +Functional testing ATE_FUN.1 PASS +Independent testing - sample ATE_IND.2 PASS +Vulnerability assessment AVA: PASS +Vulnerability analysis AVA_VAN.2 PASS + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +15 (18) +10 Evaluator Comments and Recommendations +None. + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +16 (18) +11 Glossary +CC Common Criteria version 3.1 +EAL Evaluation Assurance Level +FIPS Federal Information Processing Standard +IDM Identity Manager +ITSEF +IT Security Evaluation Facility, test labora- +tory licensed to operate within a evaluation +and certification scheme +NTP Network Time Protocol +OSP Organizational Security Policy +OSP One SSO Provider +SSO Single Sign On +SFP Security Function Policy +SFR Security Functional Requirement +SSPR Self Service Password Reset +ST Security Target +TOE Target of Evaluation + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +17 (18) +12 Bibliography +ST NetIQ Identity Manager 4.7 Security Target (ST), NetIQ +Corporation, 2020-06-01, document version 2.6 +QSIM Quick Start Guide for Installing NetIQ Identity Manager 4.7 +February 2018 +SUL NetIQ Identity Manager Setup Guide for Linux February 2018 +AGD NetIQ Identity Manager 4.7, Operational User Guidance and +Preparative Procedures Supplement (AGD-IGS), version 0.6 +CCpart1 Common Criteria for Information Technology Security Evaluation, +Part 1, version 3.1 revision 5, CCMB-2017-04-001 +CCpart2 Common Criteria for Information Technology Security Evaluation, +Part 2, version 3.1 revision 5, CCMB-2017-04-002 +CCpart3 Common Criteria for Information Technology Security +Evaluation,Part 3, version 3.1 revision 5, CCMB-2017-04-003 +CC CCpart1 + CCpart2 + CCpart3 +CEM Common Methodology for Information Technology Security +Evaluation, version 3.1 revision 5, CCMB-2017-04-004 +SP-002 SP-002 Evaluation and Certification, CSEC, 2019-09-24, document +version 31.0 + Swedish Certification Body for IT Security +Certification Report NetIQ® Identity Manager 4.7 +18FMV7705-43:1 1.0 2020-06-15 +18 (18) +Appendix A Scheme Versions +During the certification the following versions of the Swedish Common Criteria Eval- +uation and Certification scheme have been used. +A.1 Scheme/Quality Management System +During the certification project, the following versions of the quality management sys- +tem (QMS) have been applicable since the certification application was received: +QMS 1.21.5 valid from 2018-11-19 +QMS 1.22 valid from 2019-02-01 +QMS 1.22.1 valid from 2019-03-08 +QMS 1.22.2 valid from 2019-05-02 +QMS 1.22.3 valid from 2019-05-20 +QMS 1.23 valid from 2019-10-14 +QMS 1.23.1 valid from 2020-03-06 +QMS 1.23.2 valid from 2020-05-11 +In order to ensure consistency in the outcome of the certification, the certifier has ex- +amined the changes introduced in each update of the quality management system. +The changes between consecutive versions are outlined in “Ändringslista CSEC QMS +1.23.1”. The certifier concluded that, from QMS 1.21.5 to the current QMS 1.23.2, +there are no changes with impact on the result of the certification. +Note that the SP-188 Scheme Crypto Policy version 9.0 was introduced in QMS 1.23. +The certification application was submitted before the SP-188 Scheme Crypto Policy +version 9.0 was introduced and therefore version 8.0 was used. +A.2 Scheme Notes +The following Scheme interpretations have been considered during the certification. + Scheme Note 15 - Demonstration of test Coverage + Scheme Note 18 - Highlighted Requirements on the Security Target + Scheme Note 22 - Vulnerability assessment + Scheme Note 28 - Updated procedures for application, evaluation and certification + \ No newline at end of file diff --git a/tests/data/cc/dataset/target_309ac2fd7f2dcf17.txt b/tests/data/cc/dataset/target_309ac2fd7f2dcf17.txt deleted file mode 100644 index 6f86c7be..00000000 --- a/tests/data/cc/dataset/target_309ac2fd7f2dcf17.txt +++ /dev/null @@ -1,1497 +0,0 @@ -NetIQ Identity Manager 4.7 -Security Target (ST) -Date: June 1, 2020 -Version: 2.6 -Prepared By: NetIQ Corporation -Prepared For: NetIQ Corporation -515 Post Oak Blvd -Suite 1200 -Houston, Texas 77027 -Abstract -This document provides the basis for an evaluation of a specific Target of Evaluation (TOE), Identity -Manager 4.7. This Security Target (ST) defines a set of assumptions about the aspects of the environment, -a list of threats that the product intends to counter, a set of security objectives, a set of security requirements -and the IT security functions provided by the TOE which meet the set of requirements. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 2 of 36 -Table of Contents -Table of Contents...................................................................................................................................2 -List of Tables.........................................................................................................................................3 -List of Figures........................................................................................................................................4 -1. Introduction ...........................................................................................................................................5 -Security Target Reference:............................................................................................................5 -TOE Reference..............................................................................................................................5 -Document Organization................................................................................................................5 -Document Conventions.................................................................................................................6 -Document Terminology................................................................................................................6 -TOE Overview..............................................................................................................................7 -TOE Description...........................................................................................................................8 -Administration Workstation (Console):........................................................................................8 -Identity Applications (RBPM)......................................................................................................8 -Identity Manager:..........................................................................................................................9 -Reporting Server:..........................................................................................................................9 -Log Manager:................................................................................................................................9 -OneSSO Provider:.........................................................................................................................9 -Self Service Password Reset:......................................................................................................10 -TOE Delivery:.............................................................................................................................10 -TOE Environment.......................................................................................................................10 -Virtual Machines.........................................................................................................................10 -Hardware and Software Supplied by the IT Environment..........................................................11 -Logical Boundary........................................................................................................................11 -TOE Security Functional Policies...............................................................................................12 -Discretionary Access Control SFP..............................................................................................12 -TOE Vendor Documentation / Guidance....................................................................................12 -Features / Functionality NOT Included in the TOE....................................................................12 -2. Conformance Claims ...........................................................................................................................14 -CC Conformance Claim..............................................................................................................14 -PP Claim .....................................................................................................................................14 -Package Claim ............................................................................................................................14 -Conformance Rationale...............................................................................................................14 -3. Security Problem Definition................................................................................................................15 -Threats.........................................................................................................................................15 -Organizational Security Policies.................................................................................................15 -Assumptions................................................................................................................................15 -4. Security Objectives..............................................................................................................................17 -Security Objectives for the TOE.................................................................................................17 -Security Objectives for the Operational Environment................................................................17 -Security Objectives Rationale.....................................................................................................17 -Mapping of Objectives................................................................................................................18 -5. Extended Components Definition........................................................................................................20 -6. Security Requirements.........................................................................................................................21 -Security Functional Requirements..............................................................................................21 -Security Audit (FAU) .................................................................................................................21 -FAU_GEN.1 Audit Data Generation..........................................................................................21 -FAU_SAR.1 Audit Review.........................................................................................................22 - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 3 of 36 -Cryptographic Support................................................................................................................22 -FCS_CKM.1 Cryptographic key generation...............................................................................22 -FCS_CKM.4 Cryptographic key destruction..............................................................................22 -FCS_COP.1 Cryptographic operation (Encryption / Decryption) ..............................................22 -Information Flow Control (FDP) ................................................................................................23 -FDP_ACC.1 Subset Access Control...........................................................................................23 -FDP_ACF.1 Security Attribute Based Access Control...............................................................23 -Identification and Authentication (FIA) .....................................................................................24 -FIA_ATD.1 – User Attribute Definition.....................................................................................24 -FIA_UAU.2 User Authentication before Any Action ................................................................24 -FIA_UID.2 User Identification before Any Action....................................................................24 -Security Management (FMT)......................................................................................................24 -FMT_MSA.1 Management of security attributes .......................................................................24 -FMT_MSA.2 Secure Security Attributes....................................................................................24 -FMT_MSA.3 Static Attribute Initialization................................................................................24 -FMT_MTD.1 Management of TSF Data....................................................................................25 -FMT_SMF.1 Specification of Management Functions ..............................................................25 -FMT_SMR.1 Security Roles.......................................................................................................25 -Protection of the TSF (FPT)........................................................................................................25 -FPT_TDC.1 Inter-TSF Basic TSF Data Consistency .................................................................25 -Trusted Path / Channel (FTP) .....................................................................................................26 -FTP_ITC.1 Inter-TSF trusted channel ........................................................................................26 -FTP_TRP.1 Trusted Path............................................................................................................26 -Security Assurance Requirements ..............................................................................................26 -Security Requirements Rationale................................................................................................26 -Security Functional Requirements..............................................................................................26 -Dependency Rationale ................................................................................................................27 -Sufficiency of Security Requirements ........................................................................................28 -Security Assurance Requirements ..............................................................................................30 -Security Assurance Requirements Rationale ..............................................................................30 -Security Assurance Requirements Evidence...............................................................................31 -7. TOE Summary Specification...............................................................................................................33 -TOE Security Functions..............................................................................................................33 -Security Audit.............................................................................................................................33 -Identification and Authentication................................................................................................33 -User Data Protection...................................................................................................................33 -Security Management .................................................................................................................34 -Trusted Path / Channels ..............................................................................................................35 -Trusted Channel..........................................................................................................................35 -Trusted Path:...............................................................................................................................35 -Cryptographic Support................................................................................................................35 -List of Tables -Table 1 – ST Organization and Section Descriptions...................................................................................6 -Table 2 – Acronyms Used in Security Target...............................................................................................7 -Table 3 – CAVP Certificate Numbers ..........................................................................................................9 -Table 4 – Virtual Machine Environment Requirements .............................................................................11 -Table 5 – IT Environment Component Requirements................................................................................11 -Table 6 – Logical Boundary Descriptions ..................................................................................................12 -Table 7 – IT Environment Components - Not In TOE ...............................................................................13 - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 4 of 36 -Table 8 – Threats Addressed by the TOE...................................................................................................15 -Table 9 – Organizational Security Policies.................................................................................................15 -Table 10 – Assumptions..............................................................................................................................16 -Table 11 – TOE Security Objectives ..........................................................................................................17 -Table 12 – Operational Environment Security Objectives .........................................................................17 -Table 13 – Mapping of Assumptions, Threats, Policies and ORSP s to Security Objectives.....................18 -Table 14 – Mapping of Threats, Policies, and Assumptions to Objectives ................................................19 -Table 15 – TOE Security Functional Requirements ...................................................................................21 -Table 16 – Cryptographic Standards...........................................................................................................22 -Table 17 – Cryptographic Operations.........................................................................................................23 -Table 18 – Management of TSF data..........................................................................................................25 -Table 19 – Mapping of TOE Security Functional Requirements and Objectives.......................................27 -Table 20 – Mapping of SFR to Dependencies and Rationales....................................................................28 -Table 20 – Rationale for TOE SFRs to Objectives.....................................................................................30 -Table 22 – Security Assurance Requirements at EAL3..............................................................................30 -Table 23 – Security Assurance Rationale and Measures ............................................................................32 -Table 24 – Roles and Functions..................................................................................................................34 -Table 22 – CAVP........................................................................................................................................36 -List of Figures -Figure 1 – TOE Deployment with Subsystems.............................................................................................7 -Figure 2 – Sample Download List ..............................................................................................................10 - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 5 of 36 -1. Introduction -This section identifies the Security Target (ST), Target of Evaluation (TOE), Security Target -organization, document conventions, and terminology. It also includes an overview of the -evaluated product. -Security Target Reference: -ST Title NetIQ Identity Manager 4.7 Security Target: -ST Revision 2.6 -ST Publication Date June 1, 2020 -ST Author Michael F. Angelo -TOE Reference -TOE Reference NetIQ Identity Manager 4.7 -TOE Developer NetIQ Corporation -Evaluation Assurance Level (EAL) EAL3+ -Note: The file download name is: Identity_Manager_4.7_Linux.iso . -Note: The official name of the product is NetIQ Identity Manager 4.7 Advanced Edition. The -released product can be uniquely identified as: NetIQ Identity Manager 4.7.3. The product name -may also be abbreviated as Identity Manager 4.7 AE, Identity Manager, IDM 4.7.3AE or IDM 4.7 -or simply IDM . Finally the TOE, if examined for the build number will be identified as NetIQ -Identity Manager 4.7.3.0.317. For the purpose of this document all of the above references are -equivalent, and the document may refer to the product simply as IDM or the TOE. -Document Organization -This Security Target follows the following format: -SECTION TITLE DESCRIPTION -1 Introduction Provides an overview of the TOE and defines the -hardware and software that make up the TOE as well -as the physical and logical boundaries of the TOE -2 Conformance Claims Lists evaluation conformance to Common Criteria -versions, Protection Profiles, or Packages where -applicable -3 Security Problem -Definition -Specifies the threats, assumptions and organizational -security policies that affect the TOE -4 Security Objectives Defines the security objectives for the -TOE/operational environment and provides a -rationale to demonstrate that the security objectives -satisfy the threats -5 Extended -Components -Definition -Describes extended components of the evaluation (if -any) -6 Security -Requirements -Contains the functional and assurance requirements -for this TOE - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 6 of 36 -SECTION TITLE DESCRIPTION -7 TOE Summary -Specification -Identifies the IT security functions provided by the -TOE and also identifies the assurance measures -targeted to meet the assurance requirements. -Table 1 – ST Organization and Section Descriptions -Document Conventions -The notation, formatting, and conventions used in this Security Target are consistent with those -used in Version 3.1 of the Common Criteria. Selected presentation choices are discussed here -to aid the Security Target reader. The Common Criteria allows several operations to be -performed on functional requirements: The allowable operations defined in Part 2 of the -Common Criteria are refinement, selection, assignment and iteration. - The refinement operation is used to add detail to a requirement, and thus further -restricts a requirement. Refinement of security requirements is denoted by bold text. -Any text removed is indicated with a strikethrough format (Example: TSF). - The selection operation is picking one or more items from a list in order to narrow the -scope of a component element. Selections are denoted by italicized text. - The assignment operation is used to assign a specific value to an unspecified parameter, -such as the length of a password. An assignment operation is indicated by showing the -value in square brackets, i.e. [assignment_value(s)]. - Iterated functional and assurance requirements are given unique identifiers by -appending to the base requirement identifier from the Common Criteria an iteration -number inside parenthesis, for example, FMT_MTD.1.1 (1) and FMT_MTD.1.1 (2) refer -to separate instances of the FMT_MTD.1 security functional requirement component. -When not embedded in a Security Functional Requirement, italicized text is used for both -official document titles and text meant to be emphasized more than plain text. -Document Terminology -The following table describes the acronyms used in this document: -TERM DEFINITION -CC Common Criteria version 3.1 -EAL Evaluation Assurance Level -IDM Identity Manager -IDV Identity Vault -IGA Identity Governance and Administration -NMAS NetIQ Modular Authentication Service -NTP Network Time Protocol -ORSP Organizational Security Policy -OSP One SSO Provider -SSO Single Sign On -SFP Security Function Policy -SFR Security Functional Requirement -SLM Sentinel Log Manager - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 7 of 36 -TERM DEFINITION -SSPR Self Service Password Reset -ST Security Target -TOE Target of Evaluation -TSF TOE Security Function -Table 2 – Acronyms Used in Security Target -TOE Overview -The TOE is NetIQ Identity Manager 4.7. NetIQ Identity Manager provides data sharing and -synchronization services which enable applications, directories, and databases to share -information. It links scattered information and enables you to establish policies that govern -automatic updates to designated systems when identity changes occur. -Identity Manager provides the foundation for account provisioning, security, single sign-on, -user self-service, authentication, authorization, automated workflow, and Web services. It -allows you to integrate, manage, and control your distributed identity information so you can -securely deliver the right resources to the right people. -The following diagram shows a typical TOE deployment: -Identity Reporting Module -Operating System -General Purpose Computing -Platform -Reporting Server -Sentinel Log Management -for Identity Governance -and Administration -Operating System -General Purpose Computing -Platform -Log Manager -Identity Manager Engine -Identity Vault -Operating System -General Purpose Computing -Platform -Identity Applications -(RBPM) -Web Browser -Operating System -General Purpose Computing -(GPC) Platform -Identity Application -4 -1 -2 -8 -10 -= TOE Component -= IT Environment Component -One SSO Provider -(uname / pass, Kerberos, -SAML) -Operating System -General Purpose Computing -Platform -3 -5 -SSO Provider -Self Service Password -Reset -Web Browser -Operating System -General Purpose Computing -Platform -Self Service Password Reset -11 -9 -12 -7a -Identity Manager -6 -B -Administration -Workstation -(Console) 7b -Separate communication paths to Sentinel Log Manager -7a – Identity Vault to Sentinel Log Manager -7b – iManager to Sentinel Log Manager -C -A -iManager -Designer / Analyzer -= TOE Sub Component -OpenSSL -Figure 1 – TOE Deployment with Subsystems1 -The TOE provides the following functions: data synchronization, role management, -auditing/reporting, and management. -11 -Note the Administration Workstation Console is not included in the evaluation as there is no code that is added to it to make it -explicitly a workstation console. It is included in the document as a component required for access.to the TOE. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 8 of 36 - Data synchronization, including password synchronization, is provided by the base -components of the Identity Manager solution: the Identity Vault, Identity Manager -engine, drivers, Remote Loader, and connected applications - Role management is provided by the User Application - Auditing and reporting are provided by the Identity Reporting Module -TOE Description -NetIQ Identity Manager 4.7 is a comprehensive identity management suite. It provides an -intelligent identity framework that leverages your existing IT assets and new computing -models like Software as a Service (SaaS) by reducing cost and ensuring compliance across -physical, virtual, and cloud environments. With the NetIQ Identity Manager solution, you can -make sure that your business has the most current user identity information. You can retain -control at the enterprise level by managing, provisioning, and de-provisioning identities within -the firewall and extending to the cloud. Through streamlined user administration and -processes, Identity Manager helps organizations reduce management costs, increase -productivity and security, and comply with government regulations. -The TOE is a software TOE and includes the following functions. -Each function contains the components as follows: -1. Administration Workstation (Console)2 -2. Identity Applications (RBPM) 4.7.3.0.1109 - Designer aka Identity Manager Designer 4.7.3.0.20190614 - Analyzer aka Identity Manager Analyzer -3. Identity Manager - Identity Manager Engine 4.7.3.0.AE -o Identity Vault 9.1.4 -o iManager 3.1.4 -4. Reporting Server - Identity Reporting Module 6.5.0. F14508F -5. Log Manager - Sentinel Log Management for Identity Governance and Administration 8.2.2.0_5415 -6. SSO Provider - One SSO Provider (OSP) 6.3.3.0 -7. Self Service Password Reset - Self Service Password Reset (SSPR) 4.4.0.2 B366 r39762 -Administration Workstation (Console): -The Administration Workstation (Console) is used to access the Identity Applications (RBPM), -Identity Manager, and the Reporting Server. Each of these functions is described below. -Identity Applications (RBPM) -The Identity Applications (RBPM) houses the Designer / Analyzer functions. The Identity -Application is a Web application (browser-based) that gives users and business administrators -the ability to perform a variety of identity self-service and roles provisioning tasks, including -managing passwords and identity data, initiating and monitoring provisioning and role -assignment requests, managing the approval process for provisioning requests, and verifying -2 -The Administration Workstation (Console) is not part of the TOE, in that there is no code added to it in order to function as the -Console it is required to access features and function of the TOE and is included for completeness. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 9 of 36 -attestation reports. It includes the workflow engine that controls the routing of requests -through the appropriate approval process. Designer aka Designer for Identity Manager helps -you design, test, document, and deploy Identity Manager solutions in a network or test -environment. Analyzer aka NetIQ Analyzer for Identity Manager is an identity management -toolset that helps you ensure that internal data quality policies are adhered to by providing -data analysis, data cleansing, data reconciliation, and data monitoring/reporting. Analyzer lets -you analyze, enhance, and control all data stores throughout the enterprise. -Identity Manager: -The Identity Manager houses the Identity Manager Engine (and the Identity Vault which -contains the Identity Applications data) and iManager. The Identity Manager Engine -synchronizes identity data between applications. For example, data synchronized from a -PeopleSoft system to Lotus Notes is first added to the Identity Vault and then sent to the Lotus -Notes system. In addition, the Identity Vault stores information specific to Identity Manager, -such as driver configurations, parameters, and policies. -The following packages are used to provide cryptographic functions, and are not included in -the TOE boundary. NetIQ eDirectory is used for the Identity Vault. eDirectory provides access -to the OpenSSL Cryptographic functionality. -They meet the cryptographic quality requirements as evidenced by the following certificates: -Component CAVP Cert # -AES Certs. #3090 and #3264 -HMAC Certs. #1937 and #2063 -RSA Certs. #1581 and #1664 -Table 3 – CAVP Certificate Numbers -Reporting Server: -The reporting server houses the Identity Reporting Module. The Identity Reporting Module -generates reports that show critical business information about various aspects of your -Identity Manager configuration, including information collected from Identity Vaults and -managed systems such as Active Directory or SAP. The reporting module provides a set of -predefined report definitions you can use to generate reports. In addition, it gives you the -option to import custom reports defined in a third-party tool. The user interface for the -reporting module makes it easy to schedule reports to run at off-peak times to optimize -performance. -The IDM Tools are used to manage the Identity Manager solution. This includes functions to: - Analyze, enhance, and control all data stores throughout the enterprise - Design, deploy, and document the TOE - Manage Identity Manager and receive real-time health and status information -about the Identity Manager system - Define and maintain which authorizations are associated with which business roles -Log Manager: -The Log Manager, also known as Sentinel Log Manager for Identity Governance and -Administration (SLM for IGA), collects and acknowledges receipt of auditing data from all -aspects of the product. -OneSSO Provider: - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 10 of 36 -The OneSSO Provider, also known as OSP) is a single interface for access authentication. This -provider can handle user name / password, Kerberos, and SAML tokens. -Self Service Password Reset: -Self Service Password Reset (SSPR) allows users to enroll, update, and reset their passwords -without administrative intervention in the Identity Vault (IDV). -Note: that the components above can be installed on one or multiple distributed systems. Also, -the hardware, operating systems and third-party support software (e.g. DBMS) on each of the -systems are excluded from the TOE boundary. -TOE Delivery: -The TOE software is provided to customers via secure download from the download portal -(https://dl.netiq.com/index.jsp). The software is available as either a gnu zip (.gz), iso -formatted optical disk (.iso). zip (.zip) or dmg (if mac) depending on your destination platform. -Once downloaded, and extracted, the setup files can be executed to perform the installation. -Figure 2 – Sample Download List -TOE Environment -Virtual Machines -The following TOE components can be installed in virtual machines (VM). - Console / Administration Workstation (Identity Applications) - Identity Manager - Reporting Server - Sentinel Log Manager - One SSO Provider - Self Service Password Reset (SSPR) -The hardware and software requirements for the operational environment to support the VM -are listed in the table below: - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 11 of 36 -Category Console / -Administration -Workstation -(Identity -Applications3) -Identity -Manager -(Identity -Manager -Engine) -Reporting -Server -(Identity -Reporting -Module) -Log -Manager -(SLM for -Identity -Gov & -Adm) -SSO -Provider -(OneSSO -Provider) -Self Service -Password Reset -(SSPR) -Processor 2 CPU cores 2 CPU -cores -2 CPU -cores -4 to 8 CPU -cores -2 CPU -cores -2 CPU cores -Memory 8 GB 8 GB 8 GB 8 to 16 GB 8 GB 8 GB -Table 4 – Virtual Machine Environment Requirements -Hardware and Software Supplied by the IT Environment -The TOE consists of a set of software applications run on one or multiple distributed systems. -The TOE requires the following software components as part of the evaluated configuration: -Component Requirements -Administration Workstation Mozilla Firefox 65 -Identity Applications (RBPM) -Designer / Analyzer) -SUSE Linux Enterprise Server 12 SP4 -Identity Manager (Identity -Manager Engine) -SUSE Linux Enterprise Server 12 SP4 -Reporting Server (Identity -Reporting Module) -SUSE Linux Enterprise Server 12 SP4 -Log Manager (Sentinel Log -Management for Identity -Governance and -Administration) -SUSE Linux Enterprise Server 12 SP4 -SSO Provider (OneSSO -Provider) -SUSE Linux Enterprise Server 12 SP4 -Self Service Password Reset SUSE Linux Enterprise Server 12 SP4 -Table 5 – IT Environment Component Requirements -In addition to the platform requirements mentioned above, the following hardware resources -are needed in order to install and configure Identity Manager on each platform: - A minimum of 8 GB RAM - 15 GB available disk space to install all the components. - Additional disk space to configure and populate data. This might vary depending -on your connected systems and number of objects in the Identity Vault. -For server-based components, it is recommended that the platform have a minimum of 2 CPUs -or cores -Logical Boundary -This section outlines the boundaries of the security functionality of the TOE; the logical -boundary of the TOE includes the security functionality described in the following table: -3 -The system requirements also apply to the following components that you use with the identity applications: PostgreSQL, Tomcat, -NetIQ One SSO Provider (OSP), and NetIQ Self Service Password Reset. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 12 of 36 -TSF DESCRIPTION -Security -Management -The TOE restricts the ability to enable, modify and disable security -policy rules and user roles to an authorized Administrator. The TOE -also provides the functions necessary for effective management of -the TOE security functions. Administrators configure the TOE with -the Management Console via Web-based connection. -Security Audit The TOE supports the provision of log data from each system -component, such as user login/logout and incident/ticket -management actions. It also records security events such as failed -login attempts, etc. Audit trails can be stored for later review and -analysis. -Cryptographic -Support -The TOE utilizes the OpenSSL cryptographic module to provide -support for HTTPS / TLS communications with administrators and -TOE components. -Identification and -Authentication -The TOE enforces individual I&A. Operators must successfully -authenticate using a unique identifier and password prior to -performing any actions on the TOE. -User Data -Protection -The TOE enforces discretionary access rules using an access control -list with user attributes. -Trusted Path / -Channels -The TOE utilizes HTTPS/TLS to provide trusted paths and inter-TSF -trusted channels. -Table 6 – Logical Boundary Descriptions -TOE Security Functional Policies -The TOE supports the following Security Functional Policy: -Discretionary Access Control SFP -The TOE implements an access control SFP named Discretionary Access Control SFP. This SFP -determines and enforces the privileges associated with operator roles. An authorized -administrator can define specific services available to administrators and users via the -Management Console. -TOE Vendor Documentation / Guidance -In addition to the documentation generated for the certification, the TOE includes the following -product and guidance documentation generated by NetIQ: - Quick Start Guide for Installing NetIQ Identity Manager 4.7 February 2018 - NetIQ Identity Manager Setup Guide for Linux February 2018 - NetIQ Identity Manager 4.7, Operational User Guidance and Preparative Procedures -Supplement (AGD-IGS), version 0.6, is supplied for those customers that need -guidance on how to set the TOE in the evaluated configuration. -Features / Functionality NOT Included in the TOE -The following supported operating systems and software were not included in the evaluated -configuration: -Functions Requirements -Administration Workstation (Console) Web Browsers - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 13 of 36 -Functions Requirements - Internet Explorer 11 - Google Chrome -Identity Applications (Includes Designer / -Analyzer) -RHEL 7.5 -Windows Server 2016 -Identity Manager (Includes Identity Vault -and, iManager) -RHEL 7.5 -Windows Server 2016 -Reporting Server -(includes Identity Reporting Module) -RHEL 7.5 -Windows Server 2016 -Log Manager (includes Sentinel Log -Management for Identity Governance and -Administration) -RHEL 7.5 -One SSO Provider (uname / pass, Kerberos, -SAML) -RHEL 7.5 -Windows Server 2016 -Self Service Password Reset (SSPR) RHEL 7.5 -Windows Server 2016 -Table 7 – IT Environment Components - Not In TOE - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 14 of 36 -2. Conformance Claims -CC Conformance Claim -The TOE is Common Criteria Version 3.1 Revision 5 (April 2017) Part 2 conformant and Part 3 -conformant. -PP Claim -The TOE does not claim conformance to any registered Protection Profile. -Package Claim -The TOE claims conformance to the EAL3 assurance package defined in Part 3 of the Common -Criteria Version 3.1 Revision 5 (April 2017). The TOE does not claim conformance to any -functional package. The TOE EAL3 assurance package is augmented with ALC_FLR.2 -Conformance Rationale -No conformance rationale is necessary for this evaluation since this Security Target does not -claim conformance to a Protection Profile. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 15 of 36 -3. Security Problem Definition -In order to clarify the nature of the security problem that the TOE is intended to solve, this -section describes the following: - Any known or assumed threats to the assets against which specific protection within the TOE or -its environment is required - Any organizational security policy statements or rules with which the TOE must comply - Any assumptions about the security aspects of the environment and/or of the manner in which -the TOE is intended to be used. -This chapter identifies assumptions as A.assumption, threats as T.threat and policies as P.policy. -Threats -The following are threats identified for the TOE and the IT System (or operating environment) -the TOE monitors. The TOE itself has threats and the TOE is also responsible for addressing -threats to the environment in which it resides. The assumed level of expertise of the attacker -for all threats is unsophisticated. -The TOE addresses the following threats: -THREAT DESCRIPTION -T.NO_AUTH An unauthorized user may gain access to the TOE and alter the -TOE configuration. -T.NO_PRIV An authorized user of the TOE exceeds his/her assigned -security privileges resulting in unauthorized modification of the -TOE configuration and/or data. -T.USER_ACCESS_DENY An authorized user may be able to change user authentication data -and or user access policies and deny their access to it later. -T.PASSWD_COMPROMISE An unauthorized user may be able to obtain and use user -passwords. -T.PROT_TRANS An unauthorized user may be able to gather information from -communications between components. -Table 8 – Threats Addressed by the TOE -Organizational Security Policies -The TOE meets the following organizational security policies: -ASSUMPTION DESCRIPTION -P.REMOTE_DATA Passwords and account information from network-attached systems -shall be monitored and managed. -Table 9 – Organizational Security Policies -Assumptions -The TOE is assured to provide effective security measures in a co-operative non-hostile -environment only if it is installed, managed, and used correctly. The following specific -conditions are assumed to exist in an environment where the TOE is employed. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 16 of 36 -ASSUMPTION DESCRIPTION -A.MANAGE Administrators of the TOE are assumed to be appropriately trained to -undertake the installation, configuration and management of the TOE -in a secure and trusted manner. -A.NOEVIL Administrators of the TOE and users on the local area network are not -careless, willfully negligent, nor hostile, and will follow and abide by the -instructions provided by the TOE documentation -A.LOCATE The processing platforms on which the TOE resides are assumed to be -located within a facility that provides controlled access -A.CONFIG The TOE is configured to receive all passwords and associated data -from network-attached systems. -A.TIMESOURCE The TOE has a trusted source for system time via NTP server -Table 10 – Assumptions - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 17 of 36 -4. Security Objectives -Security Objectives for the TOE -The IT security objectives for the TOE are addressed below: -OBJECTIVE DESCRIPTION -O.MANAGE_DATA The TOE shall provide a means to manage secrets and data associated -with remote IT systems. -O.MANAGE_POLICY The TOE shall provide a workflow to manage authentication and access -control policies. -O.SEC_ACCESS The TOE shall ensure that only those authorized users and applications -are granted access to security functions and associated data. -O.PASSWD_PROT The TOE shall provide cryptographic mechanisms to protect passwords -via cryptographic processes including the ability to generate and destroy -keys. -O.TRANS_PROT The TOE shall provide mechanisms to protect data that is in transit -between elements within the TOE. -Table 11 – TOE Security Objectives -Security Objectives for the Operational Environment -The security objectives for the operational environment are addressed below: -OBJECTIVE DESCRIPTION -OE.TIME The TOE operating environment shall provide an accurate timestamp -(via reliable NTP server). -OE.ENV_PROTECT The TOE operating environment shall provide mechanisms to isolate the -TOE Security Functions (TSF) and assure that TSF components cannot -be tampered with or bypassed -OE.PERSONNEL Authorized administrators are non-hostile and follow all administrator -guidance and must ensure that the TOE is delivered, installed, managed, -and operated in a manner that maintains the TOE security objectives. -Any operator of the TOE must be trusted not to disclose their -authentication credentials to any individual not authorized for access to -the TOE. -OE.PHYSEC The facility surrounding the processing platform in which the TOE -resides must provide a controlled means of access into the facility -Table 12 – Operational Environment Security Objectives -Security Objectives Rationale - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 18 of 36 -This section provides the summary that all security objectives are traced back to aspects of the -addressed assumptions, threats, and Organizational Security Policies. -OBJECTIVES THREATS/ -ASSUMPTIONS/ POLICIES -O.MANAGE_DATA -O.MANAGE_POLICY -O.SEC_ACCESS -O.PASSWD_PROT -O.TRANS_PROT -OE.TIME -OE.ENV_PROTECT -OE.PERSONNEL -OE.PHYSEC -A.CONFIG    -A.MANAGE  -A.NOEVIL  -A.LOCATE  -A.TIMESOURCE  -T.NO_AUTH  -T.NO_PRIV  -T.USER_ACCESS_DENY  -T.PASSWD_COMPROMISE  -T.PROT_TRANS  -P. REMOTE_DATA  -Table 13 – Mapping of Assumptions, Threats, Policies and ORSP s to Security Objectives -Mapping of Objectives -ASSUMPTION /THREAT/ -POLICY -RATIONALE -A.CONFIG This assumption is addressed by - OE.ENV_PROTECT, which ensures that TSF components -cannot be tampered with or bypassed - OE.PERSONNEL, which ensures that the TOE is managed -and administered by in a secure manner by a competent -and security aware personnel in accordance with the -administrator documentation. This objective also ensures -that those responsible for the TOE install, manage, and -operate the TOE in a secure manner - OE.PHYSEC, which ensures that the facility surrounding the -processing platform in which the TOE resides provides a -controlled means of access into the facility - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 19 of 36 -ASSUMPTION /THREAT/ -POLICY -RATIONALE -A.MANAGE This assumption is addressed by - OE.PERSONNEL, which ensures that the TOE is managed -and administered by in a secure manner by a competent -and security aware personnel in accordance with the -administrator documentation. This objective also ensures -that those responsible for the TOE install, manage, and -operate the TOE in a secure manner -A.NOEVIL This assumption is addressed by OE.PERSONNEL, which ensures -that the TOE is managed and administered by in a secure manner -by a competent and security aware personnel in accordance with -the administrator documentation. This objective also ensures -that those responsible for the TOE install, manage, and operate -the TOE in a secure manner -A.LOCATE This assumption is addressed by OE.PHYSEC which ensures that -the facility surrounding the processing platform in which the -TOE resides provides a controlled means of access into the -facility -A.TIMESOURCE This assumption is addressed by OE.TIME, which ensures the -provision of an accurate time source. -T.NO_AUTH This threat is countered by the following: - O.SEC_ACCESS, which ensures that the TOE allows access to -the security functions, configuration, and associated data -only by authorized users and applications -T.NO_PRIV This threat is countered by O.SEC_ACCESS, which ensures that -the TOE allows access to the security functions, configuration, -and associated data only by authorized users and applications. -T.PASSWD_COMPROMISE This threat is countered by O.PASSWD_PROT, which ensures -the passwords are not in the clear and cannot be exposed to un -authorized users for use. -T.PROT_TRANS This threat is countered by O.TRANS_PROT, which protects data -that is in transit between elements within the TOE. -P.REMOTE_DATA This organizational security policy is enforced by - O.MANAGE_DATA, which ensures that the TOE provide a -means to manage secrets and data associated with remote -IT systems. -T.USER_ACCESS_DENY This threat is countered by O.MANAGE_POLICY which ensures -that the TOE provides a workflow to manage authentication and -access control policies. -Table 14 – Mapping of Threats, Policies, and Assumptions to Objectives - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 20 of 36 -5. Extended Components Definition -This Security Target does include any extended components. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 21 of 36 -6. Security Requirements -The security requirements that are levied on the TOE and the IT environment are specified in -this section of the ST. -Security Functional Requirements -The functional security requirements for this Security Target consist of the following -components from Part 2 of the CC, which are summarized in the following table: -CLASS HEADING CLASS_FAMILY DESCRIPTION -Security Audit -FAU_GEN.1 Audit Data Generation -FAU_SAR.1 Audit Review -Cryptographic Support FCS_CKM.1 Cryptographic key generation -FCS_CKM.4 Cryptographic key destruction -FCS_COP.1 Cryptographic operation -User Data Protection -FDP_ACC.1 Subset Access Control -FDP_ACF.1 Security Attribute Based Access Control -Identification and -Authentication -FIA_ATD.1 User Attribute Definition -FIA_UID.2 User Identification before Any Action -FIA_UAU.2 User Authentication before Any Action -Security Management -FMT_MSA.1 Management of Security Attributes -FMT_MSA.2 Secure Security Attributes -FMT_MSA.3 Static Attribute Initialization -FMT_MTD.1 Management of TSF Data -FMT_SMF.1 Specification of Management Functions -FMT_SMR.1 Security Roles -Protection of the TSF FPT_TDC.1 Inter-TSF basic TSF data consistency -Trusted Path / Channels -FTP_ITC.1 Trusted Channel -FTP_TRP.1 Trusted Path -Table 15 – TOE Security Functional Requirements -Security Audit (FAU) -FAU_GEN.1 Audit Data Generation -FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following -auditable events: -a) Start-up and shutdown of the audit functions; -b) All auditable events for the [not specified] level of audit; and -c) [User login/logout and; -d) Login failures;] - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 22 of 36 -FAU_GEN.1.2 The TSF shall record within each audit record at least the following -information: -a) Date and time of the event, type of event, subject identity (if -applicable), and the outcome (success or failure) of the event; -and -b) For each audit event type, based on the auditable event -definitions of the functional components included in the PP/ST, -[no other audit relevant information]. -FAU_SAR.1 Audit Review -FAU_SAR.1.1 The TSF shall provide [the Administrator] with the capability to read -[all audit data generated within the TOE] from the audit records. -FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the -user to interpret the information. -Cryptographic Support -FCS_CKM.1 Cryptographic key generation -FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a -specified cryptographic key generation algorithm [cryptographic key -generation algorithm in Table 16] and specified cryptographic key -sizes [cryptographic key sizes in Table 16] that meet the following: [list -of standards in Table 16]. -Usage Key Generation Algorithm Key Size (bits), Elliptical Curves Standard -RSA RSA Key Generation 2048 FIPS 186-4 -AES Deterministic Random Bit -Generator (DRBG) -128, 256 SP 800-90A -Diffie-Hellman Diffie-Hellman Key -Generation -1024, 2048 FIPS 186-4 -Table 16 – Cryptographic Standards -FCS_CKM.4 Cryptographic key destruction -FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a -specified cryptographic key destruction method [zeroize] that meets -the following: [FIPS 140-2]. -FCS_COP.1 Cryptographic operation (Encryption / Decryption) -FCS_COP.1.1 The TSF shall perform [cryptographic operations in Table 17] in -accordance with a specified cryptographic algorithm [cryptographic -algorithm in Table 17] and cryptographic key sizes [cryptographic key -sizes in Table 17] that meet the following: [list of standards in Table -17]. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 23 of 36 -Application Note: AES in CBC mode is used for encrypting/decrypting -data in support of TLS. -Operation Algorithm Key Size, Curve or -Digest -Standard -Encryption and -Decryption in support of -TLS -AES (Advanced -Encryption -Standard) -128, 256 FIPS PUB -197 -Key agreement in -support TLS -Key Agreement -Schemes (KAS) and -Key Confirmation -P-256, P384, P521 SP800- -56A -Authentication algorithm -in support of TLS -ECDSA (Elliptic -Curve Digital -Signature -Algorithm) -P-256, P384, P521 FIPS 186-4 -Secure Hashing in -support of TLS -Secure Hash -Algorithm (SHA) -160 (SHA-1) -256 (SHA-256) -384 (SHA-384) -FIPS PUB -180-4 -Message Authentication -in support of TLS -Keyed-Hash -Message -Authentication Code -(HMAC) -160 (HMAC-SHA1) 256 -(HMAC-SHA2-256) 384 -(HMAC-SHA2-384) -FIPS 198-1 -Asymmetric -cryptography in support -of TLS -Rivest, Shamir, -Adleman (RSA) -2048 FIPS 186-4 -Table 17 – Cryptographic Operations -Information Flow Control (FDP) -FDP_ACC.1 Subset Access Control -FDP_ACC.1.1 The TSF shall enforce the [Discretionary Access Control SFP] on [ -Subjects: All users -Objects: System reports, component audit logs, TOE configuration, -operator account attributes -Operations: all user actions] -FDP_ACF.1 Security Attribute Based Access Control -FDP_ACF.1.1 The TSF shall enforce the [Discretionary Access Control SFP]to objects -based on the following: [ -Subjects: All users -Objects: System reports, component audit logs, TOE configuration, -operator account attributes -Operations: all user actions] -FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation -among controlled subjects and controlled objects is allowed: [if the - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 24 of 36 -ACL identifies the user or a group of users that contains the user -requesting access for the type of resource that the user is requesting, -and the user (or group of users) has the specific rights required for the -type of operation requested on the object then the user is granted -access]. -FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based -on the following additional rules: [password restrictions, login -restrictions, time based access controls, ip access controls, intruder -lockout]. -FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the -following additional rules [ password restrictions, login restrictions, -time based access controls, ip access controls, intruder lockout] -Identification and Authentication (FIA) -FIA_ATD.1 – User Attribute Definition -FIA_ATD.1.1 The TSF shall maintain the following list of security attributes -belonging to individual users: [User Identity, Authentication Status, -and Privilege Level]. -FIA_UAU.2 User Authentication before Any Action -FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated -before allowing any other TSF-mediated actions on behalf of that user. -FIA_UID.2 User Identification before Any Action -FIA_UID.2.1 The TSF shall require each user to be successfully identified before -allowing any other TSF-mediated actions on behalf of that user. -Security Management (FMT) -FMT_MSA.1 Management of security attributes -FMT_MSA.1.1 The TSF shall enforce the [Discretionary Access Control SFP] to -restrict the ability to [query, modify, delete] the security attributes -[Accounts, privileges, ACLs] to [Administrator]. -FMT_MSA.2 Secure Security Attributes -FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for -[security attributes listed with Discretionary Access Control SFP]. -FMT_MSA.3 Static Attribute Initialization -FMT_MSA.3.1 The TSF shall enforce the [Discretionary Access Control SFP] to -provide [restrictive] default values for security attributes that are -used to enforce the SFP. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 25 of 36 -FMT_MSA.3.2 The TSF shall allow the [Administrator] to specify alternative initial -values to override the default values when an object or information -is created. -FMT_MTD.1 Management of TSF Data -FMT_MTD.1.1 The TSF shall restrict the ability to [control] the [data described in the -table below] to [Administrator]: -DATA CHANGE QUERY MODIFY DELETE CLEAR -Discretionary -Access Control SFP -     -User Account -Attributes -  -Audit Logs  -Date/Time  -Table 18 – Management of TSF data -FMT_SMF.1 Specification of Management Functions -FMT_SMF.1.1 The TSF shall be capable of performing the following management -functions: [ -a) Create accounts -b) Modify accounts -c) Define privilege levels Change Default, -Query, Modify, Delete, Clear the attributes -associated with the Discretionary Access -Control SFP -d) Modify the behavior of the Discretionary -Access Control SFP -e) Manage ACLs]. -FMT_SMR.1 Security Roles -FMT_SMR.1.1 The TSF shall maintain the roles [Administrator, User]. -FMT_SMR.1.2 The TSF shall be able to associate users with roles. -Protection of the TSF (FPT) -FPT_TDC.1 Inter-TSF Basic TSF Data Consistency -FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret [secrets -(passwords)] when shared between the TSF and another trusted IT -product. -FPT_TDC.1.2 The TSF shall use [the secret with the newest associated timestamp] -when interpreting the TSF data from another trusted IT product. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 26 of 36 -Trusted Path / Channel (FTP) -FTP_ITC.1 Inter-TSF trusted channel -FTP_ITC.1.1 The TSF shall provide a communication channel between itself and -[another trusted IT product] that is logically distinct from other -communication channels and provides assured identification of its end -points and protection of the channel data from [modification or -disclosure]. -FTP_ITC.1.2 The TSF shall permit [the TSF] to initiate communication via the -trusted channel. -FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for -[HTTPS/TLS connections - for communications labeled 1 – 12 in Figure 1] -Application Note: The TOE supports TLS v1.1 and 1.2 as configured by -the Administrator. -Application Note: Crypto as claimed in FCS_COP_1 is used to support -TLS. -FTP_TRP.1 Trusted Path -FTP_TRP.1.1 The TSF shall provide a communication path between itself and [local] -users that is logically distinct from other communication paths and -provides assured identification of its end points and protection of the -communicated data from [disclosure]. -FTP_TRP.1.2 The TSF shall permit [the TSF] to initiate communication via the -trusted path. -FTP_TRP.1.3 The TSF shall require the use of the trusted path for [key requests, and -encryption operations - for communications labeled A, B, and C in Figure 1] -Security Assurance Requirements -The Security Assurance Requirements for this evaluation are listed in Section 6.3.4 – Security -Assurance Requirements. -Security Requirements Rationale -Security Functional Requirements -The following table provides the correspondence mapping between security objectives and the -requirements that satisfy them. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 27 of 36 -OBJECTIVE -SFR -O.MANAGE_DATA -O.MANAGE_POLICY -O.SEC_ACCESS -O.PASSWD_PROT -O.TRANS_PROT -FAU_GEN.1  -FAU_SAR.1  -FCS_CKM.1  -FCS_CKM.4  -FCS_COP.1  -FDP_ACC.1  -FDP_ACF.1  -FIA_ATD.1  -FIA_UID.2  -FIA_UAU.2  -FMT_MSA.1  -FMT_MSA.2  -FMT_MSA.3  -FMT_MTD.1  -FMT_SMF.1  -FMT_SMR.1  -FPT_TDC.1  -FTP_ITC.1  -FTP_TRP.1  -Table 19 – Mapping of TOE Security Functional Requirements and Objectives -Dependency Rationale -This ST satisfies all the security functional requirement dependencies of the Common Criteria. -The table below lists each SFR to which the TOE claims conformance with a dependency and -indicates whether the dependent requirement was included. As the table indicates, all -dependencies have been met. -SFR CLAIM DEPENDENCIES DEPENDENCY MET RATIONALE -FAU_GEN.1 FPT_STM.1 YES -Satisfied by the Operational -Environment (OE.TIME) -FAU_SAR.1 -FAU_GEN.1 -FPT_STM.1 -YES -FPT_STM.1 satisfied by the -Operational Environment -(OE.TIME) - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 28 of 36 -SFR CLAIM DEPENDENCIES DEPENDENCY MET RATIONALE -FCS_CKM.1 -FCS_CKM.1 or -FCS_COP.1 and -FCS_CKM.4 -YES -Satisfied by FCS_COP.1 and -FCS_CKM.4 -FCS_CKM.4 FTP_ITC.1 or -FTP_ITC.2 or -FCS_CKM.1 -YES Satisfied by FCS_CKM.1 for AES -FCS_COP.1 FTP_ITC.1 or -FTP_ITC.2 or -FCS_CKM.1 and -FCS_CKM.4 -YES Satisfied by FCS_CKM.1 and -FCS_CKM.4 -FDP_ACC.1 FDP_ACF.1 YES -FDP_ACF.1 -FDP_ACC.1 -FMT_MSA.3 -YES -FIA_ATD.1 N/A N/A -FIA_UID.2 N/A N/A -FMT_MSA.1 -FDP_ACC.1 -FMT_SMF.1 -FMT_SMR.1 -YES -FMT_MSA.2 -FDP_ACC.1 -FMT_MSA.1 -FMT_SMR.1 -YES -FMT_MSA.3 -FMT_MSA.1 -FMT_SMR.1 -YES -FMT_MTD.1 -FMT_SMF.1 -FMT_SMR.1 -YES -FMT_SMF.1 N/A N/A -FMT_SMR.1 FIA_UID.1 YES -Although FIA_UID.1 is not -included, FIA_UID.2, which is -hierarchical to FIA_UID.1 is -included. This satisfies this -dependency. -FPT_TDC.1 N/A N/A -FTP_ITC.1 N/A N/A -FTP_TRP.1 N/A N/A -Table 20 – Mapping of SFR to Dependencies and Rationales -Sufficiency of Security Requirements -The following table presents a mapping of the rationale of TOE Security Requirements to -Objectives. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 29 of 36 -OBJECTIVE RATIONALE -O.MANAGE_DATA The objective to ensure that the TOE will collect events from security -products and non-security products deployed within a network and -applies analytical processes to derive conclusions about the events is -met by the following security requirements: - FPT_TDC.1 ensures that the TOE provides consistency between -passwords used on remote IT systems and those -stored/managed within the TOE. -O.MANAGE_POLICY The objective to ensure that the TOE provides a workflow to manage -authentication and access control policies is met by the following -security requirements: - FAU_GEN.1 and FAU_SAR.1 define the auditing capability for -incidents and administrative access control and requires that -authorized users will have the capability to read and interpret -data stored in the audit logs - FMT_SMF.1 and FMT_SMR.1 support the security functions -relevant to the TOE and ensure the definition of an authorized -administrator role -O.SEC_ACCESS This objective ensures that the TOE allows access to the security -functions, configuration, and associated data only by authorized users -and applications. - FDP_ACC.1 requires that all user actions resulting in the access -to TOE security functions and configuration data are controlled - FDP_ACF.1 supports FDP_ACC.1 by ensuring that access to TOE -security functions, configuration data, audit logs, and account -attributes is based on the user privilege level and their -allowable actions - FIA_UID.2 requires the TOE to enforce identification of all users -prior to configuration of the TOE - FIA_UAU.2 requires the TOE to enforce authentication of all -users prior to configuration of the TOE - FIA_ATD.1 specifies security attributes for users of the TOE - FMT_MTD.1 restricts the ability to query, add or modify TSF -data to authorized users. - FMT_MSA.1 specifies that only privileged administrators can -access the TOE security functions and related configuration -data. - FMT_MSA.2 specifies that only secure values are accepted for -security attributes listed with access control policies. - FMT_MSA.3 ensures that the default values of security -attributes are restrictive in nature as to enforce the access -control policy for the TOE - FTP_ITC.1 specifies that the trusted channel exists for components -HTTPS/TLS. - FTP_TRP.1 specifies that the trusted path exists for components -HTTPS/TLS. - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 30 of 36 -OBJECTIVE RATIONALE -O.PASSWD_PROT This objective ensures that the TOE provides cryptographic -mechanisms to generate and destroy keys. This objective is met by: -FCS_CKM.1, FCS_CKM. 4, and FCS_COP.1 which provide the -cryptographic support functions for secure communications within the -TOE and with external IT entities. -O.TRANS_PROT This objective ensures that the TOE protects data in transit between -elements within the TOE. This objective is met by FTP_ITC (which -specifies that the trusted channel exists for components) and FTP_TRP -(which ensures that the trusted path exists for components). -Table 21 – Rationale for TOE SFRs to Objectives -Security Assurance Requirements -The assurance security requirements for this Security Target are taken from Part 3 of the CC. -These assurance requirements compose an Evaluation Assurance Level 3 (EAL3). The assurance -components are summarized in the following table: -CLASS HEADING CLASS_FAMILY DESCRIPTION -ADV: Development -ADV_ARC.1 Security Architecture Description -ADV_FSP.3 -Functional Specification with Complete -Summary -ADV_TDS.2 Architectural Design -AGD: Guidance -Documents -AGD_OPE.1 Operational User Guidance -AGD_PRE.1 Preparative Procedures -ALC: Lifecycle Support -ALC_CMC.3 Authorization Controls -ALC_CMS.3 Implementation representation CM coverage -ALC_DEL.1 Delivery Procedures -ALC_DVS.1 Identification of Security Measures -ALC_LCD.1 Developer defined life-cycle model -ALC_FLR.2 Flaw Reporting Procedures -ATE: Tests -ATE_COV.2 Analysis of Coverage -ATE_DPT.1 Testing: Basic Design -ATE_FUN.1 Functional Testing -ATE_IND.2 Independent Testing - Sample -AVA: Vulnerability -Assessment -AVA_VAN.2 Vulnerability Analysis -Table 22 – Security Assurance Requirements at EAL3 -Security Assurance Requirements Rationale -The ST specifies Evaluation Assurance Level 3. EAL3 was chosen because it is based upon good -commercial development practices with thorough functional testing. EAL3 provides the -developers and users a moderate level of independently assured security in conventional -commercial TOEs. The threat of malicious attacks is not greater than low, the security -environment provides physical protection, and the TOE itself offers a very limited interface, - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 31 of 36 -offering essentially no opportunity for an attacker to subvert the security policies without -physical access. The product was augmented to comply with ALC_FLR.2 in order to document -and address requirements for remediation and reporting of faults that may be discovered in the -product after release. -Security Assurance Requirements Evidence -This section identifies the measures applied to satisfy CC assurance requirements. -SECURITY ASSURANCE -REQUIREMENT -EVIDENCE TITLE -ADV_ARC.1 Security Architecture -Description -NetIQ Identity Manager 4.7 -Security Architecture (ADV_ARC) -ADV_FSP.3 Functional Specification -with Complete Summary -NetIQ Identity Manager 4.7 -Functional Specification (ADV_FSP) -ADV_TDS.2 Architectural Design -NetIQ Identity Manager 4.7 -Architectural Design (IDM TDS) -AGD_OPE.1 Operational User -Guidance4 -NetIQ Identity Manager 4.7 -Operational User Guidance and Preparative -Procedures Supplement (AGD-IGS) -AGD_PRE.1Preparative Procedures -NetIQ Identity Manager 4.7 -Operational User Guidance and Preparative -Procedures Supplement (AGD-IGS) -ALC_CMC.3 Authorization Controls -NetIQ Identity Manager 4.7 -Configuration Management Processes and -Procedures (ALC_CM) -ALC_CMS.3 Implementation -representation CM coverage -NetIQ Identity Manager 4.7 -Configuration Management Processes and -Procedures (ALC_CM) -ALC_DEL.1 Delivery Procedures -NetIQ Identity Manager 4.7 -Secure Delivery Processes and Procedures -(ALC_DEL) -ALC_DVS.1 Identification of Security -Measures -NetIQ Identity Manager 4.7 -Development Security Measures (ALC_DVS) -ALC_LCD.1 Developer defined life- -cycle model -NetIQ Identity Manager 4.7 -Life Cycle Development Process (ALC_LCD) -ALC_FLR.2: Flaw Remediation -Procedures -NetIQ Identity Manager 4.7 -Flaw reporting Procedures (ALC_FLR) -ATE_COV.2 Analysis of Coverage -NetIQ Identity Manager 4.7 -Test Plan and Coverage Analysis (ATE) -ATE_DPT.1 Testing: Basic Design -NetIQ Identity Manager 4.7 -Test Plan and Coverage Analysis (ATE) -4 -Additional documents can be found in Appendix A - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 32 of 36 -SECURITY ASSURANCE -REQUIREMENT -EVIDENCE TITLE -ATE_FUN.1Functional Testing -NetIQ Identity Manager 4.7 -Test Plan and Coverage Analysis (ATE) -Table 23 – Security Assurance Rationale and Measures - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 33 of 36 -7. TOE Summary Specification -This section presents the Security Functions implemented by the TOE. -TOE Security Functions -The security functions performed by the TOE are as follows: - Security Management - Security Audit - Identification and Authentication - User Data Protection - Trusted Path / Channels - Cryptographic Support -Security Audit -The TOE generates the following audit data: - Start-up and shutdown of the audit functions (instantiated by startup of the TOE) - User login/logout - Login failures -The TOE provides the Administrator with the capability to read all audit data generated within -the TOE via the console. The GUI provides a suitable means for an Administrator to interpret the -information from the audit log. -The A.TIMESOURCE is added to the assumptions on operational environment, and OE.TIME is -added to the operational environment security objectives. The time and date provided by the -operational environment are used to form the timestamps. The TOE ensures that the audit trail -data is stamped when recorded with a dependable date and time received from the OE -(operating system). In this manner, accurate time and date is maintained on the TOE. -The Security Audit function is designed to satisfy the following security functional requirements: - FAU_GEN.1 - FAU_SAR.1 -Identification and Authentication -The IDM console application provides user interfaces that administrators may use to manage -TOE functions. The operating system and the database in the TOE Environment are queried to -individually authenticate administrators or users. The TOE maintains authorization information -that determines which TOE functions an authenticated administrators or users (of a given role) -may perform. -The TOE maintains the following list of security attributes belonging to individual users: - User Identity (i.e., user name) - Authentication Status (whether the IT Environment validated the username/password) - Privilege Level (Administrator or User) -The Identification and Authentication function is designed to satisfy the following security -functional requirements: - FIA_ATD.1 - FIA_UAU.2 - FIA_UID.2 -User Data Protection - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 34 of 36 -The TOE implements a discretionary access control policy to define what roles can access -particular functions of the TOE. All access and actions for system reports, component audit logs, -TOE configuration, operator account attributes (defined in FIA_ATD.1) are protected via access -control list. When a user requests to perform an action on an object, the TOE verifies the role -associated with the user name. Access is granted if the user (or group of users) has the specific -rights required for the type of operation requested on the object. -Identity Manager can enforce password policies on incoming passwords from connected -systems and on passwords set or changed through the User Application password self-service. -If the new password does not comply, you can specify that Identity Manager not accept the -password. This also means that passwords that don't comply with your policies are not -distributed to other connected systems. -In addition, can enforce password policies on connected systems. If the password being -published to the Identity Vault does not comply with rules in a policy, you can specify that -Identity Manager not only does not accept the password for distribution, but actually resets the -noncompliant password on the connected system by using the current Distribution password in -the Identity Vault. -The User Data Protection function is designed to satisfy the following security functional -requirements: - FDP_ACC.1 - FDP_ACF.1 - FPT_TDC.1 -Security Management -The TOE maintains the operator roles described in the following table. The individual roles are -categorized into two main roles: the Administrator and the User. -ROLE MANAGEMENT FUNCTIONS -Administrator A user who has rights to configure and manage all aspects of the TOE -User The user’s capabilities can be configured to: -View hierarchical relationships between User objects -View and edit user information (with appropriate rights). -Search for users or resources using advanced search criteria -(which can be saved for later reuse). -Recover forgotten passwords. -Table 24 – Roles and Functions -Only an Administrator can determine the behavior of, disable, enable, and modify the behavior -of the functions that implement the Discretionary Access Control SFP. The TPE ensures only -secure values are accepted for the security attributes listed with Discretionary Access Control -SFP. -The Security Management function is designed to satisfy the following security functional -requirements: - FMT_MTD.1 - FMT_MSA.1 - FMT_MSA.2 - FMT_MSA.3 - FMT_SMF.1 - FMT_SMR.1 - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 35 of 36 -Trusted Path / Channels -The Trusted Path/Channels function is designed to satisfy the following security functional -requirements: - FTP_ITC.1 – the TOE supports establishment of trusted channels for communicating -TOE entities using HTTPS. - FTP_TRP.1 – the TOE provides a trusted path for TOE Users, using HTTPS -Trusted Channel -The TOE provides a trusted channel between the TOE and external web servers. -Trusted channels are implemented using HTTPS. The TOE supports TLS v1.1 and TLS v1.2. The -TOE supports the following TLS cipher suites, as defined in RFC 2246, RFC 4346 and RFC 5246: - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_ CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 -Trusted Path: -The TOE provides a trusted path for TOE administrators and TOE users to communicate with -the TOE. The trusted path is implemented using HTTPS. The TOE’s implementation of TLS is -described in the previous section (Trusted Channel). -Cryptographic Support -Cryptographic protection of data in transit between the TOE and remote users, and between -the TOE and external web servers is provided by the OpenSSL FIPS Object Module software -version 2.0.10 (Cryptographic Module Validation Program (CMVP) certificate number 1747) -libraries. -The following table identifies the CAVP algorithm certificates. -Operation Algorithm CAVP Certificate -Encryption and Decryption in -support of TLS -AES (Advanced Encryption -Standard) -AES 3264 -Key Generation in support of -TLS -DRBG (Deterministic -Random Bit Generation) -DRBG 723 -Key agreement in support of -TLS -Key Agreement Schemes -(KAS) and Key Confirmation -CVL 472 -Keyed-Hash Message -Authentication in support of -TLS -HMAC-SHA1, HMAC-SHA2- -256, HMAC-SHA2-384 -HMAC 2063 -Secure Hash in support of TLS SHA-1, SHA-256, SHA-384 SHS 2702 - June 1, 2020 NetIQ Identity Manager 4.7 ST -NetIQ Corporation Page 36 of 36 -Asymmetric cryptography in -support of TLS -RSA RSA 1664 -Authentication algorithm in -support of TLS -ECDSA ECDSA 620 -Table 25 – CAVP -The Cryptographic Support function is designed to satisfy the following security functional -requirements: - FCS_CKM.1 - FCS_CKM.4 - FCS_COP.1 - \ No newline at end of file diff --git a/tests/data/cc/dataset/target_e3dcf91ef38ddbf0.txt b/tests/data/cc/dataset/target_e3dcf91ef38ddbf0.txt new file mode 100644 index 00000000..6f86c7be --- /dev/null +++ b/tests/data/cc/dataset/target_e3dcf91ef38ddbf0.txt @@ -0,0 +1,1497 @@ +NetIQ Identity Manager 4.7 +Security Target (ST) +Date: June 1, 2020 +Version: 2.6 +Prepared By: NetIQ Corporation +Prepared For: NetIQ Corporation +515 Post Oak Blvd +Suite 1200 +Houston, Texas 77027 +Abstract +This document provides the basis for an evaluation of a specific Target of Evaluation (TOE), Identity +Manager 4.7. This Security Target (ST) defines a set of assumptions about the aspects of the environment, +a list of threats that the product intends to counter, a set of security objectives, a set of security requirements +and the IT security functions provided by the TOE which meet the set of requirements. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 2 of 36 +Table of Contents +Table of Contents...................................................................................................................................2 +List of Tables.........................................................................................................................................3 +List of Figures........................................................................................................................................4 +1. Introduction ...........................................................................................................................................5 +Security Target Reference:............................................................................................................5 +TOE Reference..............................................................................................................................5 +Document Organization................................................................................................................5 +Document Conventions.................................................................................................................6 +Document Terminology................................................................................................................6 +TOE Overview..............................................................................................................................7 +TOE Description...........................................................................................................................8 +Administration Workstation (Console):........................................................................................8 +Identity Applications (RBPM)......................................................................................................8 +Identity Manager:..........................................................................................................................9 +Reporting Server:..........................................................................................................................9 +Log Manager:................................................................................................................................9 +OneSSO Provider:.........................................................................................................................9 +Self Service Password Reset:......................................................................................................10 +TOE Delivery:.............................................................................................................................10 +TOE Environment.......................................................................................................................10 +Virtual Machines.........................................................................................................................10 +Hardware and Software Supplied by the IT Environment..........................................................11 +Logical Boundary........................................................................................................................11 +TOE Security Functional Policies...............................................................................................12 +Discretionary Access Control SFP..............................................................................................12 +TOE Vendor Documentation / Guidance....................................................................................12 +Features / Functionality NOT Included in the TOE....................................................................12 +2. Conformance Claims ...........................................................................................................................14 +CC Conformance Claim..............................................................................................................14 +PP Claim .....................................................................................................................................14 +Package Claim ............................................................................................................................14 +Conformance Rationale...............................................................................................................14 +3. Security Problem Definition................................................................................................................15 +Threats.........................................................................................................................................15 +Organizational Security Policies.................................................................................................15 +Assumptions................................................................................................................................15 +4. Security Objectives..............................................................................................................................17 +Security Objectives for the TOE.................................................................................................17 +Security Objectives for the Operational Environment................................................................17 +Security Objectives Rationale.....................................................................................................17 +Mapping of Objectives................................................................................................................18 +5. Extended Components Definition........................................................................................................20 +6. Security Requirements.........................................................................................................................21 +Security Functional Requirements..............................................................................................21 +Security Audit (FAU) .................................................................................................................21 +FAU_GEN.1 Audit Data Generation..........................................................................................21 +FAU_SAR.1 Audit Review.........................................................................................................22 + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 3 of 36 +Cryptographic Support................................................................................................................22 +FCS_CKM.1 Cryptographic key generation...............................................................................22 +FCS_CKM.4 Cryptographic key destruction..............................................................................22 +FCS_COP.1 Cryptographic operation (Encryption / Decryption) ..............................................22 +Information Flow Control (FDP) ................................................................................................23 +FDP_ACC.1 Subset Access Control...........................................................................................23 +FDP_ACF.1 Security Attribute Based Access Control...............................................................23 +Identification and Authentication (FIA) .....................................................................................24 +FIA_ATD.1 – User Attribute Definition.....................................................................................24 +FIA_UAU.2 User Authentication before Any Action ................................................................24 +FIA_UID.2 User Identification before Any Action....................................................................24 +Security Management (FMT)......................................................................................................24 +FMT_MSA.1 Management of security attributes .......................................................................24 +FMT_MSA.2 Secure Security Attributes....................................................................................24 +FMT_MSA.3 Static Attribute Initialization................................................................................24 +FMT_MTD.1 Management of TSF Data....................................................................................25 +FMT_SMF.1 Specification of Management Functions ..............................................................25 +FMT_SMR.1 Security Roles.......................................................................................................25 +Protection of the TSF (FPT)........................................................................................................25 +FPT_TDC.1 Inter-TSF Basic TSF Data Consistency .................................................................25 +Trusted Path / Channel (FTP) .....................................................................................................26 +FTP_ITC.1 Inter-TSF trusted channel ........................................................................................26 +FTP_TRP.1 Trusted Path............................................................................................................26 +Security Assurance Requirements ..............................................................................................26 +Security Requirements Rationale................................................................................................26 +Security Functional Requirements..............................................................................................26 +Dependency Rationale ................................................................................................................27 +Sufficiency of Security Requirements ........................................................................................28 +Security Assurance Requirements ..............................................................................................30 +Security Assurance Requirements Rationale ..............................................................................30 +Security Assurance Requirements Evidence...............................................................................31 +7. TOE Summary Specification...............................................................................................................33 +TOE Security Functions..............................................................................................................33 +Security Audit.............................................................................................................................33 +Identification and Authentication................................................................................................33 +User Data Protection...................................................................................................................33 +Security Management .................................................................................................................34 +Trusted Path / Channels ..............................................................................................................35 +Trusted Channel..........................................................................................................................35 +Trusted Path:...............................................................................................................................35 +Cryptographic Support................................................................................................................35 +List of Tables +Table 1 – ST Organization and Section Descriptions...................................................................................6 +Table 2 – Acronyms Used in Security Target...............................................................................................7 +Table 3 – CAVP Certificate Numbers ..........................................................................................................9 +Table 4 – Virtual Machine Environment Requirements .............................................................................11 +Table 5 – IT Environment Component Requirements................................................................................11 +Table 6 – Logical Boundary Descriptions ..................................................................................................12 +Table 7 – IT Environment Components - Not In TOE ...............................................................................13 + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 4 of 36 +Table 8 – Threats Addressed by the TOE...................................................................................................15 +Table 9 – Organizational Security Policies.................................................................................................15 +Table 10 – Assumptions..............................................................................................................................16 +Table 11 – TOE Security Objectives ..........................................................................................................17 +Table 12 – Operational Environment Security Objectives .........................................................................17 +Table 13 – Mapping of Assumptions, Threats, Policies and ORSP s to Security Objectives.....................18 +Table 14 – Mapping of Threats, Policies, and Assumptions to Objectives ................................................19 +Table 15 – TOE Security Functional Requirements ...................................................................................21 +Table 16 – Cryptographic Standards...........................................................................................................22 +Table 17 – Cryptographic Operations.........................................................................................................23 +Table 18 – Management of TSF data..........................................................................................................25 +Table 19 – Mapping of TOE Security Functional Requirements and Objectives.......................................27 +Table 20 – Mapping of SFR to Dependencies and Rationales....................................................................28 +Table 20 – Rationale for TOE SFRs to Objectives.....................................................................................30 +Table 22 – Security Assurance Requirements at EAL3..............................................................................30 +Table 23 – Security Assurance Rationale and Measures ............................................................................32 +Table 24 – Roles and Functions..................................................................................................................34 +Table 22 – CAVP........................................................................................................................................36 +List of Figures +Figure 1 – TOE Deployment with Subsystems.............................................................................................7 +Figure 2 – Sample Download List ..............................................................................................................10 + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 5 of 36 +1. Introduction +This section identifies the Security Target (ST), Target of Evaluation (TOE), Security Target +organization, document conventions, and terminology. It also includes an overview of the +evaluated product. +Security Target Reference: +ST Title NetIQ Identity Manager 4.7 Security Target: +ST Revision 2.6 +ST Publication Date June 1, 2020 +ST Author Michael F. Angelo +TOE Reference +TOE Reference NetIQ Identity Manager 4.7 +TOE Developer NetIQ Corporation +Evaluation Assurance Level (EAL) EAL3+ +Note: The file download name is: Identity_Manager_4.7_Linux.iso . +Note: The official name of the product is NetIQ Identity Manager 4.7 Advanced Edition. The +released product can be uniquely identified as: NetIQ Identity Manager 4.7.3. The product name +may also be abbreviated as Identity Manager 4.7 AE, Identity Manager, IDM 4.7.3AE or IDM 4.7 +or simply IDM . Finally the TOE, if examined for the build number will be identified as NetIQ +Identity Manager 4.7.3.0.317. For the purpose of this document all of the above references are +equivalent, and the document may refer to the product simply as IDM or the TOE. +Document Organization +This Security Target follows the following format: +SECTION TITLE DESCRIPTION +1 Introduction Provides an overview of the TOE and defines the +hardware and software that make up the TOE as well +as the physical and logical boundaries of the TOE +2 Conformance Claims Lists evaluation conformance to Common Criteria +versions, Protection Profiles, or Packages where +applicable +3 Security Problem +Definition +Specifies the threats, assumptions and organizational +security policies that affect the TOE +4 Security Objectives Defines the security objectives for the +TOE/operational environment and provides a +rationale to demonstrate that the security objectives +satisfy the threats +5 Extended +Components +Definition +Describes extended components of the evaluation (if +any) +6 Security +Requirements +Contains the functional and assurance requirements +for this TOE + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 6 of 36 +SECTION TITLE DESCRIPTION +7 TOE Summary +Specification +Identifies the IT security functions provided by the +TOE and also identifies the assurance measures +targeted to meet the assurance requirements. +Table 1 – ST Organization and Section Descriptions +Document Conventions +The notation, formatting, and conventions used in this Security Target are consistent with those +used in Version 3.1 of the Common Criteria. Selected presentation choices are discussed here +to aid the Security Target reader. The Common Criteria allows several operations to be +performed on functional requirements: The allowable operations defined in Part 2 of the +Common Criteria are refinement, selection, assignment and iteration. + The refinement operation is used to add detail to a requirement, and thus further +restricts a requirement. Refinement of security requirements is denoted by bold text. +Any text removed is indicated with a strikethrough format (Example: TSF). + The selection operation is picking one or more items from a list in order to narrow the +scope of a component element. Selections are denoted by italicized text. + The assignment operation is used to assign a specific value to an unspecified parameter, +such as the length of a password. An assignment operation is indicated by showing the +value in square brackets, i.e. [assignment_value(s)]. + Iterated functional and assurance requirements are given unique identifiers by +appending to the base requirement identifier from the Common Criteria an iteration +number inside parenthesis, for example, FMT_MTD.1.1 (1) and FMT_MTD.1.1 (2) refer +to separate instances of the FMT_MTD.1 security functional requirement component. +When not embedded in a Security Functional Requirement, italicized text is used for both +official document titles and text meant to be emphasized more than plain text. +Document Terminology +The following table describes the acronyms used in this document: +TERM DEFINITION +CC Common Criteria version 3.1 +EAL Evaluation Assurance Level +IDM Identity Manager +IDV Identity Vault +IGA Identity Governance and Administration +NMAS NetIQ Modular Authentication Service +NTP Network Time Protocol +ORSP Organizational Security Policy +OSP One SSO Provider +SSO Single Sign On +SFP Security Function Policy +SFR Security Functional Requirement +SLM Sentinel Log Manager + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 7 of 36 +TERM DEFINITION +SSPR Self Service Password Reset +ST Security Target +TOE Target of Evaluation +TSF TOE Security Function +Table 2 – Acronyms Used in Security Target +TOE Overview +The TOE is NetIQ Identity Manager 4.7. NetIQ Identity Manager provides data sharing and +synchronization services which enable applications, directories, and databases to share +information. It links scattered information and enables you to establish policies that govern +automatic updates to designated systems when identity changes occur. +Identity Manager provides the foundation for account provisioning, security, single sign-on, +user self-service, authentication, authorization, automated workflow, and Web services. It +allows you to integrate, manage, and control your distributed identity information so you can +securely deliver the right resources to the right people. +The following diagram shows a typical TOE deployment: +Identity Reporting Module +Operating System +General Purpose Computing +Platform +Reporting Server +Sentinel Log Management +for Identity Governance +and Administration +Operating System +General Purpose Computing +Platform +Log Manager +Identity Manager Engine +Identity Vault +Operating System +General Purpose Computing +Platform +Identity Applications +(RBPM) +Web Browser +Operating System +General Purpose Computing +(GPC) Platform +Identity Application +4 +1 +2 +8 +10 += TOE Component += IT Environment Component +One SSO Provider +(uname / pass, Kerberos, +SAML) +Operating System +General Purpose Computing +Platform +3 +5 +SSO Provider +Self Service Password +Reset +Web Browser +Operating System +General Purpose Computing +Platform +Self Service Password Reset +11 +9 +12 +7a +Identity Manager +6 +B +Administration +Workstation +(Console) 7b +Separate communication paths to Sentinel Log Manager +7a – Identity Vault to Sentinel Log Manager +7b – iManager to Sentinel Log Manager +C +A +iManager +Designer / Analyzer += TOE Sub Component +OpenSSL +Figure 1 – TOE Deployment with Subsystems1 +The TOE provides the following functions: data synchronization, role management, +auditing/reporting, and management. +11 +Note the Administration Workstation Console is not included in the evaluation as there is no code that is added to it to make it +explicitly a workstation console. It is included in the document as a component required for access.to the TOE. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 8 of 36 + Data synchronization, including password synchronization, is provided by the base +components of the Identity Manager solution: the Identity Vault, Identity Manager +engine, drivers, Remote Loader, and connected applications + Role management is provided by the User Application + Auditing and reporting are provided by the Identity Reporting Module +TOE Description +NetIQ Identity Manager 4.7 is a comprehensive identity management suite. It provides an +intelligent identity framework that leverages your existing IT assets and new computing +models like Software as a Service (SaaS) by reducing cost and ensuring compliance across +physical, virtual, and cloud environments. With the NetIQ Identity Manager solution, you can +make sure that your business has the most current user identity information. You can retain +control at the enterprise level by managing, provisioning, and de-provisioning identities within +the firewall and extending to the cloud. Through streamlined user administration and +processes, Identity Manager helps organizations reduce management costs, increase +productivity and security, and comply with government regulations. +The TOE is a software TOE and includes the following functions. +Each function contains the components as follows: +1. Administration Workstation (Console)2 +2. Identity Applications (RBPM) 4.7.3.0.1109 + Designer aka Identity Manager Designer 4.7.3.0.20190614 + Analyzer aka Identity Manager Analyzer +3. Identity Manager + Identity Manager Engine 4.7.3.0.AE +o Identity Vault 9.1.4 +o iManager 3.1.4 +4. Reporting Server + Identity Reporting Module 6.5.0. F14508F +5. Log Manager + Sentinel Log Management for Identity Governance and Administration 8.2.2.0_5415 +6. SSO Provider + One SSO Provider (OSP) 6.3.3.0 +7. Self Service Password Reset + Self Service Password Reset (SSPR) 4.4.0.2 B366 r39762 +Administration Workstation (Console): +The Administration Workstation (Console) is used to access the Identity Applications (RBPM), +Identity Manager, and the Reporting Server. Each of these functions is described below. +Identity Applications (RBPM) +The Identity Applications (RBPM) houses the Designer / Analyzer functions. The Identity +Application is a Web application (browser-based) that gives users and business administrators +the ability to perform a variety of identity self-service and roles provisioning tasks, including +managing passwords and identity data, initiating and monitoring provisioning and role +assignment requests, managing the approval process for provisioning requests, and verifying +2 +The Administration Workstation (Console) is not part of the TOE, in that there is no code added to it in order to function as the +Console it is required to access features and function of the TOE and is included for completeness. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 9 of 36 +attestation reports. It includes the workflow engine that controls the routing of requests +through the appropriate approval process. Designer aka Designer for Identity Manager helps +you design, test, document, and deploy Identity Manager solutions in a network or test +environment. Analyzer aka NetIQ Analyzer for Identity Manager is an identity management +toolset that helps you ensure that internal data quality policies are adhered to by providing +data analysis, data cleansing, data reconciliation, and data monitoring/reporting. Analyzer lets +you analyze, enhance, and control all data stores throughout the enterprise. +Identity Manager: +The Identity Manager houses the Identity Manager Engine (and the Identity Vault which +contains the Identity Applications data) and iManager. The Identity Manager Engine +synchronizes identity data between applications. For example, data synchronized from a +PeopleSoft system to Lotus Notes is first added to the Identity Vault and then sent to the Lotus +Notes system. In addition, the Identity Vault stores information specific to Identity Manager, +such as driver configurations, parameters, and policies. +The following packages are used to provide cryptographic functions, and are not included in +the TOE boundary. NetIQ eDirectory is used for the Identity Vault. eDirectory provides access +to the OpenSSL Cryptographic functionality. +They meet the cryptographic quality requirements as evidenced by the following certificates: +Component CAVP Cert # +AES Certs. #3090 and #3264 +HMAC Certs. #1937 and #2063 +RSA Certs. #1581 and #1664 +Table 3 – CAVP Certificate Numbers +Reporting Server: +The reporting server houses the Identity Reporting Module. The Identity Reporting Module +generates reports that show critical business information about various aspects of your +Identity Manager configuration, including information collected from Identity Vaults and +managed systems such as Active Directory or SAP. The reporting module provides a set of +predefined report definitions you can use to generate reports. In addition, it gives you the +option to import custom reports defined in a third-party tool. The user interface for the +reporting module makes it easy to schedule reports to run at off-peak times to optimize +performance. +The IDM Tools are used to manage the Identity Manager solution. This includes functions to: + Analyze, enhance, and control all data stores throughout the enterprise + Design, deploy, and document the TOE + Manage Identity Manager and receive real-time health and status information +about the Identity Manager system + Define and maintain which authorizations are associated with which business roles +Log Manager: +The Log Manager, also known as Sentinel Log Manager for Identity Governance and +Administration (SLM for IGA), collects and acknowledges receipt of auditing data from all +aspects of the product. +OneSSO Provider: + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 10 of 36 +The OneSSO Provider, also known as OSP) is a single interface for access authentication. This +provider can handle user name / password, Kerberos, and SAML tokens. +Self Service Password Reset: +Self Service Password Reset (SSPR) allows users to enroll, update, and reset their passwords +without administrative intervention in the Identity Vault (IDV). +Note: that the components above can be installed on one or multiple distributed systems. Also, +the hardware, operating systems and third-party support software (e.g. DBMS) on each of the +systems are excluded from the TOE boundary. +TOE Delivery: +The TOE software is provided to customers via secure download from the download portal +(https://dl.netiq.com/index.jsp). The software is available as either a gnu zip (.gz), iso +formatted optical disk (.iso). zip (.zip) or dmg (if mac) depending on your destination platform. +Once downloaded, and extracted, the setup files can be executed to perform the installation. +Figure 2 – Sample Download List +TOE Environment +Virtual Machines +The following TOE components can be installed in virtual machines (VM). + Console / Administration Workstation (Identity Applications) + Identity Manager + Reporting Server + Sentinel Log Manager + One SSO Provider + Self Service Password Reset (SSPR) +The hardware and software requirements for the operational environment to support the VM +are listed in the table below: + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 11 of 36 +Category Console / +Administration +Workstation +(Identity +Applications3) +Identity +Manager +(Identity +Manager +Engine) +Reporting +Server +(Identity +Reporting +Module) +Log +Manager +(SLM for +Identity +Gov & +Adm) +SSO +Provider +(OneSSO +Provider) +Self Service +Password Reset +(SSPR) +Processor 2 CPU cores 2 CPU +cores +2 CPU +cores +4 to 8 CPU +cores +2 CPU +cores +2 CPU cores +Memory 8 GB 8 GB 8 GB 8 to 16 GB 8 GB 8 GB +Table 4 – Virtual Machine Environment Requirements +Hardware and Software Supplied by the IT Environment +The TOE consists of a set of software applications run on one or multiple distributed systems. +The TOE requires the following software components as part of the evaluated configuration: +Component Requirements +Administration Workstation Mozilla Firefox 65 +Identity Applications (RBPM) +Designer / Analyzer) +SUSE Linux Enterprise Server 12 SP4 +Identity Manager (Identity +Manager Engine) +SUSE Linux Enterprise Server 12 SP4 +Reporting Server (Identity +Reporting Module) +SUSE Linux Enterprise Server 12 SP4 +Log Manager (Sentinel Log +Management for Identity +Governance and +Administration) +SUSE Linux Enterprise Server 12 SP4 +SSO Provider (OneSSO +Provider) +SUSE Linux Enterprise Server 12 SP4 +Self Service Password Reset SUSE Linux Enterprise Server 12 SP4 +Table 5 – IT Environment Component Requirements +In addition to the platform requirements mentioned above, the following hardware resources +are needed in order to install and configure Identity Manager on each platform: + A minimum of 8 GB RAM + 15 GB available disk space to install all the components. + Additional disk space to configure and populate data. This might vary depending +on your connected systems and number of objects in the Identity Vault. +For server-based components, it is recommended that the platform have a minimum of 2 CPUs +or cores +Logical Boundary +This section outlines the boundaries of the security functionality of the TOE; the logical +boundary of the TOE includes the security functionality described in the following table: +3 +The system requirements also apply to the following components that you use with the identity applications: PostgreSQL, Tomcat, +NetIQ One SSO Provider (OSP), and NetIQ Self Service Password Reset. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 12 of 36 +TSF DESCRIPTION +Security +Management +The TOE restricts the ability to enable, modify and disable security +policy rules and user roles to an authorized Administrator. The TOE +also provides the functions necessary for effective management of +the TOE security functions. Administrators configure the TOE with +the Management Console via Web-based connection. +Security Audit The TOE supports the provision of log data from each system +component, such as user login/logout and incident/ticket +management actions. It also records security events such as failed +login attempts, etc. Audit trails can be stored for later review and +analysis. +Cryptographic +Support +The TOE utilizes the OpenSSL cryptographic module to provide +support for HTTPS / TLS communications with administrators and +TOE components. +Identification and +Authentication +The TOE enforces individual I&A. Operators must successfully +authenticate using a unique identifier and password prior to +performing any actions on the TOE. +User Data +Protection +The TOE enforces discretionary access rules using an access control +list with user attributes. +Trusted Path / +Channels +The TOE utilizes HTTPS/TLS to provide trusted paths and inter-TSF +trusted channels. +Table 6 – Logical Boundary Descriptions +TOE Security Functional Policies +The TOE supports the following Security Functional Policy: +Discretionary Access Control SFP +The TOE implements an access control SFP named Discretionary Access Control SFP. This SFP +determines and enforces the privileges associated with operator roles. An authorized +administrator can define specific services available to administrators and users via the +Management Console. +TOE Vendor Documentation / Guidance +In addition to the documentation generated for the certification, the TOE includes the following +product and guidance documentation generated by NetIQ: + Quick Start Guide for Installing NetIQ Identity Manager 4.7 February 2018 + NetIQ Identity Manager Setup Guide for Linux February 2018 + NetIQ Identity Manager 4.7, Operational User Guidance and Preparative Procedures +Supplement (AGD-IGS), version 0.6, is supplied for those customers that need +guidance on how to set the TOE in the evaluated configuration. +Features / Functionality NOT Included in the TOE +The following supported operating systems and software were not included in the evaluated +configuration: +Functions Requirements +Administration Workstation (Console) Web Browsers + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 13 of 36 +Functions Requirements + Internet Explorer 11 + Google Chrome +Identity Applications (Includes Designer / +Analyzer) +RHEL 7.5 +Windows Server 2016 +Identity Manager (Includes Identity Vault +and, iManager) +RHEL 7.5 +Windows Server 2016 +Reporting Server +(includes Identity Reporting Module) +RHEL 7.5 +Windows Server 2016 +Log Manager (includes Sentinel Log +Management for Identity Governance and +Administration) +RHEL 7.5 +One SSO Provider (uname / pass, Kerberos, +SAML) +RHEL 7.5 +Windows Server 2016 +Self Service Password Reset (SSPR) RHEL 7.5 +Windows Server 2016 +Table 7 – IT Environment Components - Not In TOE + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 14 of 36 +2. Conformance Claims +CC Conformance Claim +The TOE is Common Criteria Version 3.1 Revision 5 (April 2017) Part 2 conformant and Part 3 +conformant. +PP Claim +The TOE does not claim conformance to any registered Protection Profile. +Package Claim +The TOE claims conformance to the EAL3 assurance package defined in Part 3 of the Common +Criteria Version 3.1 Revision 5 (April 2017). The TOE does not claim conformance to any +functional package. The TOE EAL3 assurance package is augmented with ALC_FLR.2 +Conformance Rationale +No conformance rationale is necessary for this evaluation since this Security Target does not +claim conformance to a Protection Profile. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 15 of 36 +3. Security Problem Definition +In order to clarify the nature of the security problem that the TOE is intended to solve, this +section describes the following: + Any known or assumed threats to the assets against which specific protection within the TOE or +its environment is required + Any organizational security policy statements or rules with which the TOE must comply + Any assumptions about the security aspects of the environment and/or of the manner in which +the TOE is intended to be used. +This chapter identifies assumptions as A.assumption, threats as T.threat and policies as P.policy. +Threats +The following are threats identified for the TOE and the IT System (or operating environment) +the TOE monitors. The TOE itself has threats and the TOE is also responsible for addressing +threats to the environment in which it resides. The assumed level of expertise of the attacker +for all threats is unsophisticated. +The TOE addresses the following threats: +THREAT DESCRIPTION +T.NO_AUTH An unauthorized user may gain access to the TOE and alter the +TOE configuration. +T.NO_PRIV An authorized user of the TOE exceeds his/her assigned +security privileges resulting in unauthorized modification of the +TOE configuration and/or data. +T.USER_ACCESS_DENY An authorized user may be able to change user authentication data +and or user access policies and deny their access to it later. +T.PASSWD_COMPROMISE An unauthorized user may be able to obtain and use user +passwords. +T.PROT_TRANS An unauthorized user may be able to gather information from +communications between components. +Table 8 – Threats Addressed by the TOE +Organizational Security Policies +The TOE meets the following organizational security policies: +ASSUMPTION DESCRIPTION +P.REMOTE_DATA Passwords and account information from network-attached systems +shall be monitored and managed. +Table 9 – Organizational Security Policies +Assumptions +The TOE is assured to provide effective security measures in a co-operative non-hostile +environment only if it is installed, managed, and used correctly. The following specific +conditions are assumed to exist in an environment where the TOE is employed. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 16 of 36 +ASSUMPTION DESCRIPTION +A.MANAGE Administrators of the TOE are assumed to be appropriately trained to +undertake the installation, configuration and management of the TOE +in a secure and trusted manner. +A.NOEVIL Administrators of the TOE and users on the local area network are not +careless, willfully negligent, nor hostile, and will follow and abide by the +instructions provided by the TOE documentation +A.LOCATE The processing platforms on which the TOE resides are assumed to be +located within a facility that provides controlled access +A.CONFIG The TOE is configured to receive all passwords and associated data +from network-attached systems. +A.TIMESOURCE The TOE has a trusted source for system time via NTP server +Table 10 – Assumptions + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 17 of 36 +4. Security Objectives +Security Objectives for the TOE +The IT security objectives for the TOE are addressed below: +OBJECTIVE DESCRIPTION +O.MANAGE_DATA The TOE shall provide a means to manage secrets and data associated +with remote IT systems. +O.MANAGE_POLICY The TOE shall provide a workflow to manage authentication and access +control policies. +O.SEC_ACCESS The TOE shall ensure that only those authorized users and applications +are granted access to security functions and associated data. +O.PASSWD_PROT The TOE shall provide cryptographic mechanisms to protect passwords +via cryptographic processes including the ability to generate and destroy +keys. +O.TRANS_PROT The TOE shall provide mechanisms to protect data that is in transit +between elements within the TOE. +Table 11 – TOE Security Objectives +Security Objectives for the Operational Environment +The security objectives for the operational environment are addressed below: +OBJECTIVE DESCRIPTION +OE.TIME The TOE operating environment shall provide an accurate timestamp +(via reliable NTP server). +OE.ENV_PROTECT The TOE operating environment shall provide mechanisms to isolate the +TOE Security Functions (TSF) and assure that TSF components cannot +be tampered with or bypassed +OE.PERSONNEL Authorized administrators are non-hostile and follow all administrator +guidance and must ensure that the TOE is delivered, installed, managed, +and operated in a manner that maintains the TOE security objectives. +Any operator of the TOE must be trusted not to disclose their +authentication credentials to any individual not authorized for access to +the TOE. +OE.PHYSEC The facility surrounding the processing platform in which the TOE +resides must provide a controlled means of access into the facility +Table 12 – Operational Environment Security Objectives +Security Objectives Rationale + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 18 of 36 +This section provides the summary that all security objectives are traced back to aspects of the +addressed assumptions, threats, and Organizational Security Policies. +OBJECTIVES THREATS/ +ASSUMPTIONS/ POLICIES +O.MANAGE_DATA +O.MANAGE_POLICY +O.SEC_ACCESS +O.PASSWD_PROT +O.TRANS_PROT +OE.TIME +OE.ENV_PROTECT +OE.PERSONNEL +OE.PHYSEC +A.CONFIG    +A.MANAGE  +A.NOEVIL  +A.LOCATE  +A.TIMESOURCE  +T.NO_AUTH  +T.NO_PRIV  +T.USER_ACCESS_DENY  +T.PASSWD_COMPROMISE  +T.PROT_TRANS  +P. REMOTE_DATA  +Table 13 – Mapping of Assumptions, Threats, Policies and ORSP s to Security Objectives +Mapping of Objectives +ASSUMPTION /THREAT/ +POLICY +RATIONALE +A.CONFIG This assumption is addressed by + OE.ENV_PROTECT, which ensures that TSF components +cannot be tampered with or bypassed + OE.PERSONNEL, which ensures that the TOE is managed +and administered by in a secure manner by a competent +and security aware personnel in accordance with the +administrator documentation. This objective also ensures +that those responsible for the TOE install, manage, and +operate the TOE in a secure manner + OE.PHYSEC, which ensures that the facility surrounding the +processing platform in which the TOE resides provides a +controlled means of access into the facility + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 19 of 36 +ASSUMPTION /THREAT/ +POLICY +RATIONALE +A.MANAGE This assumption is addressed by + OE.PERSONNEL, which ensures that the TOE is managed +and administered by in a secure manner by a competent +and security aware personnel in accordance with the +administrator documentation. This objective also ensures +that those responsible for the TOE install, manage, and +operate the TOE in a secure manner +A.NOEVIL This assumption is addressed by OE.PERSONNEL, which ensures +that the TOE is managed and administered by in a secure manner +by a competent and security aware personnel in accordance with +the administrator documentation. This objective also ensures +that those responsible for the TOE install, manage, and operate +the TOE in a secure manner +A.LOCATE This assumption is addressed by OE.PHYSEC which ensures that +the facility surrounding the processing platform in which the +TOE resides provides a controlled means of access into the +facility +A.TIMESOURCE This assumption is addressed by OE.TIME, which ensures the +provision of an accurate time source. +T.NO_AUTH This threat is countered by the following: + O.SEC_ACCESS, which ensures that the TOE allows access to +the security functions, configuration, and associated data +only by authorized users and applications +T.NO_PRIV This threat is countered by O.SEC_ACCESS, which ensures that +the TOE allows access to the security functions, configuration, +and associated data only by authorized users and applications. +T.PASSWD_COMPROMISE This threat is countered by O.PASSWD_PROT, which ensures +the passwords are not in the clear and cannot be exposed to un +authorized users for use. +T.PROT_TRANS This threat is countered by O.TRANS_PROT, which protects data +that is in transit between elements within the TOE. +P.REMOTE_DATA This organizational security policy is enforced by + O.MANAGE_DATA, which ensures that the TOE provide a +means to manage secrets and data associated with remote +IT systems. +T.USER_ACCESS_DENY This threat is countered by O.MANAGE_POLICY which ensures +that the TOE provides a workflow to manage authentication and +access control policies. +Table 14 – Mapping of Threats, Policies, and Assumptions to Objectives + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 20 of 36 +5. Extended Components Definition +This Security Target does include any extended components. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 21 of 36 +6. Security Requirements +The security requirements that are levied on the TOE and the IT environment are specified in +this section of the ST. +Security Functional Requirements +The functional security requirements for this Security Target consist of the following +components from Part 2 of the CC, which are summarized in the following table: +CLASS HEADING CLASS_FAMILY DESCRIPTION +Security Audit +FAU_GEN.1 Audit Data Generation +FAU_SAR.1 Audit Review +Cryptographic Support FCS_CKM.1 Cryptographic key generation +FCS_CKM.4 Cryptographic key destruction +FCS_COP.1 Cryptographic operation +User Data Protection +FDP_ACC.1 Subset Access Control +FDP_ACF.1 Security Attribute Based Access Control +Identification and +Authentication +FIA_ATD.1 User Attribute Definition +FIA_UID.2 User Identification before Any Action +FIA_UAU.2 User Authentication before Any Action +Security Management +FMT_MSA.1 Management of Security Attributes +FMT_MSA.2 Secure Security Attributes +FMT_MSA.3 Static Attribute Initialization +FMT_MTD.1 Management of TSF Data +FMT_SMF.1 Specification of Management Functions +FMT_SMR.1 Security Roles +Protection of the TSF FPT_TDC.1 Inter-TSF basic TSF data consistency +Trusted Path / Channels +FTP_ITC.1 Trusted Channel +FTP_TRP.1 Trusted Path +Table 15 – TOE Security Functional Requirements +Security Audit (FAU) +FAU_GEN.1 Audit Data Generation +FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following +auditable events: +a) Start-up and shutdown of the audit functions; +b) All auditable events for the [not specified] level of audit; and +c) [User login/logout and; +d) Login failures;] + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 22 of 36 +FAU_GEN.1.2 The TSF shall record within each audit record at least the following +information: +a) Date and time of the event, type of event, subject identity (if +applicable), and the outcome (success or failure) of the event; +and +b) For each audit event type, based on the auditable event +definitions of the functional components included in the PP/ST, +[no other audit relevant information]. +FAU_SAR.1 Audit Review +FAU_SAR.1.1 The TSF shall provide [the Administrator] with the capability to read +[all audit data generated within the TOE] from the audit records. +FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the +user to interpret the information. +Cryptographic Support +FCS_CKM.1 Cryptographic key generation +FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a +specified cryptographic key generation algorithm [cryptographic key +generation algorithm in Table 16] and specified cryptographic key +sizes [cryptographic key sizes in Table 16] that meet the following: [list +of standards in Table 16]. +Usage Key Generation Algorithm Key Size (bits), Elliptical Curves Standard +RSA RSA Key Generation 2048 FIPS 186-4 +AES Deterministic Random Bit +Generator (DRBG) +128, 256 SP 800-90A +Diffie-Hellman Diffie-Hellman Key +Generation +1024, 2048 FIPS 186-4 +Table 16 – Cryptographic Standards +FCS_CKM.4 Cryptographic key destruction +FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a +specified cryptographic key destruction method [zeroize] that meets +the following: [FIPS 140-2]. +FCS_COP.1 Cryptographic operation (Encryption / Decryption) +FCS_COP.1.1 The TSF shall perform [cryptographic operations in Table 17] in +accordance with a specified cryptographic algorithm [cryptographic +algorithm in Table 17] and cryptographic key sizes [cryptographic key +sizes in Table 17] that meet the following: [list of standards in Table +17]. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 23 of 36 +Application Note: AES in CBC mode is used for encrypting/decrypting +data in support of TLS. +Operation Algorithm Key Size, Curve or +Digest +Standard +Encryption and +Decryption in support of +TLS +AES (Advanced +Encryption +Standard) +128, 256 FIPS PUB +197 +Key agreement in +support TLS +Key Agreement +Schemes (KAS) and +Key Confirmation +P-256, P384, P521 SP800- +56A +Authentication algorithm +in support of TLS +ECDSA (Elliptic +Curve Digital +Signature +Algorithm) +P-256, P384, P521 FIPS 186-4 +Secure Hashing in +support of TLS +Secure Hash +Algorithm (SHA) +160 (SHA-1) +256 (SHA-256) +384 (SHA-384) +FIPS PUB +180-4 +Message Authentication +in support of TLS +Keyed-Hash +Message +Authentication Code +(HMAC) +160 (HMAC-SHA1) 256 +(HMAC-SHA2-256) 384 +(HMAC-SHA2-384) +FIPS 198-1 +Asymmetric +cryptography in support +of TLS +Rivest, Shamir, +Adleman (RSA) +2048 FIPS 186-4 +Table 17 – Cryptographic Operations +Information Flow Control (FDP) +FDP_ACC.1 Subset Access Control +FDP_ACC.1.1 The TSF shall enforce the [Discretionary Access Control SFP] on [ +Subjects: All users +Objects: System reports, component audit logs, TOE configuration, +operator account attributes +Operations: all user actions] +FDP_ACF.1 Security Attribute Based Access Control +FDP_ACF.1.1 The TSF shall enforce the [Discretionary Access Control SFP]to objects +based on the following: [ +Subjects: All users +Objects: System reports, component audit logs, TOE configuration, +operator account attributes +Operations: all user actions] +FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation +among controlled subjects and controlled objects is allowed: [if the + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 24 of 36 +ACL identifies the user or a group of users that contains the user +requesting access for the type of resource that the user is requesting, +and the user (or group of users) has the specific rights required for the +type of operation requested on the object then the user is granted +access]. +FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based +on the following additional rules: [password restrictions, login +restrictions, time based access controls, ip access controls, intruder +lockout]. +FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the +following additional rules [ password restrictions, login restrictions, +time based access controls, ip access controls, intruder lockout] +Identification and Authentication (FIA) +FIA_ATD.1 – User Attribute Definition +FIA_ATD.1.1 The TSF shall maintain the following list of security attributes +belonging to individual users: [User Identity, Authentication Status, +and Privilege Level]. +FIA_UAU.2 User Authentication before Any Action +FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated +before allowing any other TSF-mediated actions on behalf of that user. +FIA_UID.2 User Identification before Any Action +FIA_UID.2.1 The TSF shall require each user to be successfully identified before +allowing any other TSF-mediated actions on behalf of that user. +Security Management (FMT) +FMT_MSA.1 Management of security attributes +FMT_MSA.1.1 The TSF shall enforce the [Discretionary Access Control SFP] to +restrict the ability to [query, modify, delete] the security attributes +[Accounts, privileges, ACLs] to [Administrator]. +FMT_MSA.2 Secure Security Attributes +FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for +[security attributes listed with Discretionary Access Control SFP]. +FMT_MSA.3 Static Attribute Initialization +FMT_MSA.3.1 The TSF shall enforce the [Discretionary Access Control SFP] to +provide [restrictive] default values for security attributes that are +used to enforce the SFP. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 25 of 36 +FMT_MSA.3.2 The TSF shall allow the [Administrator] to specify alternative initial +values to override the default values when an object or information +is created. +FMT_MTD.1 Management of TSF Data +FMT_MTD.1.1 The TSF shall restrict the ability to [control] the [data described in the +table below] to [Administrator]: +DATA CHANGE QUERY MODIFY DELETE CLEAR +Discretionary +Access Control SFP +     +User Account +Attributes +  +Audit Logs  +Date/Time  +Table 18 – Management of TSF data +FMT_SMF.1 Specification of Management Functions +FMT_SMF.1.1 The TSF shall be capable of performing the following management +functions: [ +a) Create accounts +b) Modify accounts +c) Define privilege levels Change Default, +Query, Modify, Delete, Clear the attributes +associated with the Discretionary Access +Control SFP +d) Modify the behavior of the Discretionary +Access Control SFP +e) Manage ACLs]. +FMT_SMR.1 Security Roles +FMT_SMR.1.1 The TSF shall maintain the roles [Administrator, User]. +FMT_SMR.1.2 The TSF shall be able to associate users with roles. +Protection of the TSF (FPT) +FPT_TDC.1 Inter-TSF Basic TSF Data Consistency +FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret [secrets +(passwords)] when shared between the TSF and another trusted IT +product. +FPT_TDC.1.2 The TSF shall use [the secret with the newest associated timestamp] +when interpreting the TSF data from another trusted IT product. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 26 of 36 +Trusted Path / Channel (FTP) +FTP_ITC.1 Inter-TSF trusted channel +FTP_ITC.1.1 The TSF shall provide a communication channel between itself and +[another trusted IT product] that is logically distinct from other +communication channels and provides assured identification of its end +points and protection of the channel data from [modification or +disclosure]. +FTP_ITC.1.2 The TSF shall permit [the TSF] to initiate communication via the +trusted channel. +FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for +[HTTPS/TLS connections + for communications labeled 1 – 12 in Figure 1] +Application Note: The TOE supports TLS v1.1 and 1.2 as configured by +the Administrator. +Application Note: Crypto as claimed in FCS_COP_1 is used to support +TLS. +FTP_TRP.1 Trusted Path +FTP_TRP.1.1 The TSF shall provide a communication path between itself and [local] +users that is logically distinct from other communication paths and +provides assured identification of its end points and protection of the +communicated data from [disclosure]. +FTP_TRP.1.2 The TSF shall permit [the TSF] to initiate communication via the +trusted path. +FTP_TRP.1.3 The TSF shall require the use of the trusted path for [key requests, and +encryption operations + for communications labeled A, B, and C in Figure 1] +Security Assurance Requirements +The Security Assurance Requirements for this evaluation are listed in Section 6.3.4 – Security +Assurance Requirements. +Security Requirements Rationale +Security Functional Requirements +The following table provides the correspondence mapping between security objectives and the +requirements that satisfy them. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 27 of 36 +OBJECTIVE +SFR +O.MANAGE_DATA +O.MANAGE_POLICY +O.SEC_ACCESS +O.PASSWD_PROT +O.TRANS_PROT +FAU_GEN.1  +FAU_SAR.1  +FCS_CKM.1  +FCS_CKM.4  +FCS_COP.1  +FDP_ACC.1  +FDP_ACF.1  +FIA_ATD.1  +FIA_UID.2  +FIA_UAU.2  +FMT_MSA.1  +FMT_MSA.2  +FMT_MSA.3  +FMT_MTD.1  +FMT_SMF.1  +FMT_SMR.1  +FPT_TDC.1  +FTP_ITC.1  +FTP_TRP.1  +Table 19 – Mapping of TOE Security Functional Requirements and Objectives +Dependency Rationale +This ST satisfies all the security functional requirement dependencies of the Common Criteria. +The table below lists each SFR to which the TOE claims conformance with a dependency and +indicates whether the dependent requirement was included. As the table indicates, all +dependencies have been met. +SFR CLAIM DEPENDENCIES DEPENDENCY MET RATIONALE +FAU_GEN.1 FPT_STM.1 YES +Satisfied by the Operational +Environment (OE.TIME) +FAU_SAR.1 +FAU_GEN.1 +FPT_STM.1 +YES +FPT_STM.1 satisfied by the +Operational Environment +(OE.TIME) + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 28 of 36 +SFR CLAIM DEPENDENCIES DEPENDENCY MET RATIONALE +FCS_CKM.1 +FCS_CKM.1 or +FCS_COP.1 and +FCS_CKM.4 +YES +Satisfied by FCS_COP.1 and +FCS_CKM.4 +FCS_CKM.4 FTP_ITC.1 or +FTP_ITC.2 or +FCS_CKM.1 +YES Satisfied by FCS_CKM.1 for AES +FCS_COP.1 FTP_ITC.1 or +FTP_ITC.2 or +FCS_CKM.1 and +FCS_CKM.4 +YES Satisfied by FCS_CKM.1 and +FCS_CKM.4 +FDP_ACC.1 FDP_ACF.1 YES +FDP_ACF.1 +FDP_ACC.1 +FMT_MSA.3 +YES +FIA_ATD.1 N/A N/A +FIA_UID.2 N/A N/A +FMT_MSA.1 +FDP_ACC.1 +FMT_SMF.1 +FMT_SMR.1 +YES +FMT_MSA.2 +FDP_ACC.1 +FMT_MSA.1 +FMT_SMR.1 +YES +FMT_MSA.3 +FMT_MSA.1 +FMT_SMR.1 +YES +FMT_MTD.1 +FMT_SMF.1 +FMT_SMR.1 +YES +FMT_SMF.1 N/A N/A +FMT_SMR.1 FIA_UID.1 YES +Although FIA_UID.1 is not +included, FIA_UID.2, which is +hierarchical to FIA_UID.1 is +included. This satisfies this +dependency. +FPT_TDC.1 N/A N/A +FTP_ITC.1 N/A N/A +FTP_TRP.1 N/A N/A +Table 20 – Mapping of SFR to Dependencies and Rationales +Sufficiency of Security Requirements +The following table presents a mapping of the rationale of TOE Security Requirements to +Objectives. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 29 of 36 +OBJECTIVE RATIONALE +O.MANAGE_DATA The objective to ensure that the TOE will collect events from security +products and non-security products deployed within a network and +applies analytical processes to derive conclusions about the events is +met by the following security requirements: + FPT_TDC.1 ensures that the TOE provides consistency between +passwords used on remote IT systems and those +stored/managed within the TOE. +O.MANAGE_POLICY The objective to ensure that the TOE provides a workflow to manage +authentication and access control policies is met by the following +security requirements: + FAU_GEN.1 and FAU_SAR.1 define the auditing capability for +incidents and administrative access control and requires that +authorized users will have the capability to read and interpret +data stored in the audit logs + FMT_SMF.1 and FMT_SMR.1 support the security functions +relevant to the TOE and ensure the definition of an authorized +administrator role +O.SEC_ACCESS This objective ensures that the TOE allows access to the security +functions, configuration, and associated data only by authorized users +and applications. + FDP_ACC.1 requires that all user actions resulting in the access +to TOE security functions and configuration data are controlled + FDP_ACF.1 supports FDP_ACC.1 by ensuring that access to TOE +security functions, configuration data, audit logs, and account +attributes is based on the user privilege level and their +allowable actions + FIA_UID.2 requires the TOE to enforce identification of all users +prior to configuration of the TOE + FIA_UAU.2 requires the TOE to enforce authentication of all +users prior to configuration of the TOE + FIA_ATD.1 specifies security attributes for users of the TOE + FMT_MTD.1 restricts the ability to query, add or modify TSF +data to authorized users. + FMT_MSA.1 specifies that only privileged administrators can +access the TOE security functions and related configuration +data. + FMT_MSA.2 specifies that only secure values are accepted for +security attributes listed with access control policies. + FMT_MSA.3 ensures that the default values of security +attributes are restrictive in nature as to enforce the access +control policy for the TOE + FTP_ITC.1 specifies that the trusted channel exists for components +HTTPS/TLS. + FTP_TRP.1 specifies that the trusted path exists for components +HTTPS/TLS. + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 30 of 36 +OBJECTIVE RATIONALE +O.PASSWD_PROT This objective ensures that the TOE provides cryptographic +mechanisms to generate and destroy keys. This objective is met by: +FCS_CKM.1, FCS_CKM. 4, and FCS_COP.1 which provide the +cryptographic support functions for secure communications within the +TOE and with external IT entities. +O.TRANS_PROT This objective ensures that the TOE protects data in transit between +elements within the TOE. This objective is met by FTP_ITC (which +specifies that the trusted channel exists for components) and FTP_TRP +(which ensures that the trusted path exists for components). +Table 21 – Rationale for TOE SFRs to Objectives +Security Assurance Requirements +The assurance security requirements for this Security Target are taken from Part 3 of the CC. +These assurance requirements compose an Evaluation Assurance Level 3 (EAL3). The assurance +components are summarized in the following table: +CLASS HEADING CLASS_FAMILY DESCRIPTION +ADV: Development +ADV_ARC.1 Security Architecture Description +ADV_FSP.3 +Functional Specification with Complete +Summary +ADV_TDS.2 Architectural Design +AGD: Guidance +Documents +AGD_OPE.1 Operational User Guidance +AGD_PRE.1 Preparative Procedures +ALC: Lifecycle Support +ALC_CMC.3 Authorization Controls +ALC_CMS.3 Implementation representation CM coverage +ALC_DEL.1 Delivery Procedures +ALC_DVS.1 Identification of Security Measures +ALC_LCD.1 Developer defined life-cycle model +ALC_FLR.2 Flaw Reporting Procedures +ATE: Tests +ATE_COV.2 Analysis of Coverage +ATE_DPT.1 Testing: Basic Design +ATE_FUN.1 Functional Testing +ATE_IND.2 Independent Testing - Sample +AVA: Vulnerability +Assessment +AVA_VAN.2 Vulnerability Analysis +Table 22 – Security Assurance Requirements at EAL3 +Security Assurance Requirements Rationale +The ST specifies Evaluation Assurance Level 3. EAL3 was chosen because it is based upon good +commercial development practices with thorough functional testing. EAL3 provides the +developers and users a moderate level of independently assured security in conventional +commercial TOEs. The threat of malicious attacks is not greater than low, the security +environment provides physical protection, and the TOE itself offers a very limited interface, + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 31 of 36 +offering essentially no opportunity for an attacker to subvert the security policies without +physical access. The product was augmented to comply with ALC_FLR.2 in order to document +and address requirements for remediation and reporting of faults that may be discovered in the +product after release. +Security Assurance Requirements Evidence +This section identifies the measures applied to satisfy CC assurance requirements. +SECURITY ASSURANCE +REQUIREMENT +EVIDENCE TITLE +ADV_ARC.1 Security Architecture +Description +NetIQ Identity Manager 4.7 +Security Architecture (ADV_ARC) +ADV_FSP.3 Functional Specification +with Complete Summary +NetIQ Identity Manager 4.7 +Functional Specification (ADV_FSP) +ADV_TDS.2 Architectural Design +NetIQ Identity Manager 4.7 +Architectural Design (IDM TDS) +AGD_OPE.1 Operational User +Guidance4 +NetIQ Identity Manager 4.7 +Operational User Guidance and Preparative +Procedures Supplement (AGD-IGS) +AGD_PRE.1Preparative Procedures +NetIQ Identity Manager 4.7 +Operational User Guidance and Preparative +Procedures Supplement (AGD-IGS) +ALC_CMC.3 Authorization Controls +NetIQ Identity Manager 4.7 +Configuration Management Processes and +Procedures (ALC_CM) +ALC_CMS.3 Implementation +representation CM coverage +NetIQ Identity Manager 4.7 +Configuration Management Processes and +Procedures (ALC_CM) +ALC_DEL.1 Delivery Procedures +NetIQ Identity Manager 4.7 +Secure Delivery Processes and Procedures +(ALC_DEL) +ALC_DVS.1 Identification of Security +Measures +NetIQ Identity Manager 4.7 +Development Security Measures (ALC_DVS) +ALC_LCD.1 Developer defined life- +cycle model +NetIQ Identity Manager 4.7 +Life Cycle Development Process (ALC_LCD) +ALC_FLR.2: Flaw Remediation +Procedures +NetIQ Identity Manager 4.7 +Flaw reporting Procedures (ALC_FLR) +ATE_COV.2 Analysis of Coverage +NetIQ Identity Manager 4.7 +Test Plan and Coverage Analysis (ATE) +ATE_DPT.1 Testing: Basic Design +NetIQ Identity Manager 4.7 +Test Plan and Coverage Analysis (ATE) +4 +Additional documents can be found in Appendix A + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 32 of 36 +SECURITY ASSURANCE +REQUIREMENT +EVIDENCE TITLE +ATE_FUN.1Functional Testing +NetIQ Identity Manager 4.7 +Test Plan and Coverage Analysis (ATE) +Table 23 – Security Assurance Rationale and Measures + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 33 of 36 +7. TOE Summary Specification +This section presents the Security Functions implemented by the TOE. +TOE Security Functions +The security functions performed by the TOE are as follows: + Security Management + Security Audit + Identification and Authentication + User Data Protection + Trusted Path / Channels + Cryptographic Support +Security Audit +The TOE generates the following audit data: + Start-up and shutdown of the audit functions (instantiated by startup of the TOE) + User login/logout + Login failures +The TOE provides the Administrator with the capability to read all audit data generated within +the TOE via the console. The GUI provides a suitable means for an Administrator to interpret the +information from the audit log. +The A.TIMESOURCE is added to the assumptions on operational environment, and OE.TIME is +added to the operational environment security objectives. The time and date provided by the +operational environment are used to form the timestamps. The TOE ensures that the audit trail +data is stamped when recorded with a dependable date and time received from the OE +(operating system). In this manner, accurate time and date is maintained on the TOE. +The Security Audit function is designed to satisfy the following security functional requirements: + FAU_GEN.1 + FAU_SAR.1 +Identification and Authentication +The IDM console application provides user interfaces that administrators may use to manage +TOE functions. The operating system and the database in the TOE Environment are queried to +individually authenticate administrators or users. The TOE maintains authorization information +that determines which TOE functions an authenticated administrators or users (of a given role) +may perform. +The TOE maintains the following list of security attributes belonging to individual users: + User Identity (i.e., user name) + Authentication Status (whether the IT Environment validated the username/password) + Privilege Level (Administrator or User) +The Identification and Authentication function is designed to satisfy the following security +functional requirements: + FIA_ATD.1 + FIA_UAU.2 + FIA_UID.2 +User Data Protection + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 34 of 36 +The TOE implements a discretionary access control policy to define what roles can access +particular functions of the TOE. All access and actions for system reports, component audit logs, +TOE configuration, operator account attributes (defined in FIA_ATD.1) are protected via access +control list. When a user requests to perform an action on an object, the TOE verifies the role +associated with the user name. Access is granted if the user (or group of users) has the specific +rights required for the type of operation requested on the object. +Identity Manager can enforce password policies on incoming passwords from connected +systems and on passwords set or changed through the User Application password self-service. +If the new password does not comply, you can specify that Identity Manager not accept the +password. This also means that passwords that don't comply with your policies are not +distributed to other connected systems. +In addition, can enforce password policies on connected systems. If the password being +published to the Identity Vault does not comply with rules in a policy, you can specify that +Identity Manager not only does not accept the password for distribution, but actually resets the +noncompliant password on the connected system by using the current Distribution password in +the Identity Vault. +The User Data Protection function is designed to satisfy the following security functional +requirements: + FDP_ACC.1 + FDP_ACF.1 + FPT_TDC.1 +Security Management +The TOE maintains the operator roles described in the following table. The individual roles are +categorized into two main roles: the Administrator and the User. +ROLE MANAGEMENT FUNCTIONS +Administrator A user who has rights to configure and manage all aspects of the TOE +User The user’s capabilities can be configured to: +View hierarchical relationships between User objects +View and edit user information (with appropriate rights). +Search for users or resources using advanced search criteria +(which can be saved for later reuse). +Recover forgotten passwords. +Table 24 – Roles and Functions +Only an Administrator can determine the behavior of, disable, enable, and modify the behavior +of the functions that implement the Discretionary Access Control SFP. The TPE ensures only +secure values are accepted for the security attributes listed with Discretionary Access Control +SFP. +The Security Management function is designed to satisfy the following security functional +requirements: + FMT_MTD.1 + FMT_MSA.1 + FMT_MSA.2 + FMT_MSA.3 + FMT_SMF.1 + FMT_SMR.1 + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 35 of 36 +Trusted Path / Channels +The Trusted Path/Channels function is designed to satisfy the following security functional +requirements: + FTP_ITC.1 – the TOE supports establishment of trusted channels for communicating +TOE entities using HTTPS. + FTP_TRP.1 – the TOE provides a trusted path for TOE Users, using HTTPS +Trusted Channel +The TOE provides a trusted channel between the TOE and external web servers. +Trusted channels are implemented using HTTPS. The TOE supports TLS v1.1 and TLS v1.2. The +TOE supports the following TLS cipher suites, as defined in RFC 2246, RFC 4346 and RFC 5246: + TLS_RSA_WITH_AES_128_CBC_SHA + TLS_RSA_WITH_AES_128_GCM_SHA256 + TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA + TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 + TLS_ECDHE_ECDSA_WITH_AES_256_ CBC_SHA + TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 +Trusted Path: +The TOE provides a trusted path for TOE administrators and TOE users to communicate with +the TOE. The trusted path is implemented using HTTPS. The TOE’s implementation of TLS is +described in the previous section (Trusted Channel). +Cryptographic Support +Cryptographic protection of data in transit between the TOE and remote users, and between +the TOE and external web servers is provided by the OpenSSL FIPS Object Module software +version 2.0.10 (Cryptographic Module Validation Program (CMVP) certificate number 1747) +libraries. +The following table identifies the CAVP algorithm certificates. +Operation Algorithm CAVP Certificate +Encryption and Decryption in +support of TLS +AES (Advanced Encryption +Standard) +AES 3264 +Key Generation in support of +TLS +DRBG (Deterministic +Random Bit Generation) +DRBG 723 +Key agreement in support of +TLS +Key Agreement Schemes +(KAS) and Key Confirmation +CVL 472 +Keyed-Hash Message +Authentication in support of +TLS +HMAC-SHA1, HMAC-SHA2- +256, HMAC-SHA2-384 +HMAC 2063 +Secure Hash in support of TLS SHA-1, SHA-256, SHA-384 SHS 2702 + June 1, 2020 NetIQ Identity Manager 4.7 ST +NetIQ Corporation Page 36 of 36 +Asymmetric cryptography in +support of TLS +RSA RSA 1664 +Authentication algorithm in +support of TLS +ECDSA ECDSA 620 +Table 25 – CAVP +The Cryptographic Support function is designed to satisfy the following security functional +requirements: + FCS_CKM.1 + FCS_CKM.4 + FCS_COP.1 + \ No newline at end of file diff --git a/tests/data/cc/dataset/toy_dataset.json b/tests/data/cc/dataset/toy_dataset.json index dbf75078..cb47293b 100644 --- a/tests/data/cc/dataset/toy_dataset.json +++ b/tests/data/cc/dataset/toy_dataset.json @@ -16,7 +16,7 @@ "certs": [ { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "309ac2fd7f2dcf17", + "dgst": "e3dcf91ef38ddbf0", "status": "active", "category": "Access Control Devices and Systems", "name": "NetIQ Identity Manager 4.7", @@ -119,7 +119,7 @@ }, { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "8cf86948f02f047d", + "dgst": "ed7611868f0f9d97", "status": "active", "category": "Access Control Devices and Systems", "name": "Magic SSO V4.0", @@ -227,7 +227,7 @@ }, { "_type": "sec_certs.sample.cc.CCCertificate", - "dgst": "8a5e6bcda602920c", + "dgst": "8f08cacb49a742fb", "status": "active", "category": "Boundary Protection Devices and Systems", "name": "Fortinet FortiGate w/ FortiOS v5.6.7", -- cgit v1.3.1 From 958effe4b47bde59bca32eb64f567365590ba24a Mon Sep 17 00:00:00 2001 From: J08nY Date: Fri, 19 Jul 2024 17:12:58 +0200 Subject: Fix Spain CC scheme download. --- src/sec_certs/sample/cc_scheme.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/sec_certs/sample/cc_scheme.py b/src/sec_certs/sample/cc_scheme.py index 1af70e76..7fb9e18e 100644 --- a/src/sec_certs/sample/cc_scheme.py +++ b/src/sec_certs/sample/cc_scheme.py @@ -1306,7 +1306,7 @@ def get_spain_certified() -> list[dict[str, Any]]: "product_link": urljoin(constants.CC_SPAIN_BASE_URL, tds[0].find("a")["href"]), "category": sns(tds[1].text), "manufacturer": sns(tds[2].text), - "certification_date": sns(tds[3].find("td", class_="djc_value").text), + "certification_date": sns(tds[3].text), } results.append(cert) return results -- cgit v1.3.1 From ed3bac262f8164c6f05a428aa7933fe1545df9b5 Mon Sep 17 00:00:00 2001 From: J08nY Date: Fri, 19 Jul 2024 17:15:20 +0200 Subject: Fix scheme dataset test. --- tests/cc/test_cc_schemes.py | 2 +- .../dataset/auxiliary_datasets/scheme_dataset.json | 856 +++++++++++++++++++++ 2 files changed, 857 insertions(+), 1 deletion(-) create mode 100644 tests/data/cc/dataset/auxiliary_datasets/scheme_dataset.json diff --git a/tests/cc/test_cc_schemes.py b/tests/cc/test_cc_schemes.py index 5ae5a180..9e1e927f 100644 --- a/tests/cc/test_cc_schemes.py +++ b/tests/cc/test_cc_schemes.py @@ -222,4 +222,4 @@ def test_matching(toy_dataset: CCDataset, canada_certified): def test_process_dataset(toy_dataset: CCDataset): toy_dataset.auxiliary_datasets.scheme_dset = toy_dataset.process_schemes(True, only_schemes={"CA"}) toy_dataset._compute_scheme_data() - assert toy_dataset["8a5e6bcda602920c"].heuristics.scheme_data is not None + assert toy_dataset["8f08cacb49a742fb"].heuristics.scheme_data is not None diff --git a/tests/data/cc/dataset/auxiliary_datasets/scheme_dataset.json b/tests/data/cc/dataset/auxiliary_datasets/scheme_dataset.json new file mode 100644 index 00000000..64db2e84 --- /dev/null +++ b/tests/data/cc/dataset/auxiliary_datasets/scheme_dataset.json @@ -0,0 +1,856 @@ +{ + "_type": "sec_certs.dataset.cc_scheme.CCSchemeDataset", + "schemes": { + "CA": { + "_type": "sec_certs.sample.cc_scheme.CCScheme", + "country": "CA", + "timestamp": "2024-07-19T17:14:26.369494", + "lists": { + "INEVALUATION": [ + { + "product": "RICOH Pro C5300S/C5310S, version JE-1.20-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "Arbor Edge Defense", + "vendor": "NETSCOUT Systems, Inc.", + "level": "CPP_ND_V2.2E", + "cert_lab": "Lightship Security" + }, + { + "product": "RICOH IM C6500/C8000, version JE-1.20-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "Oracle Linux 9.3", + "vendor": "Oracle Corporation", + "level": "PP_OS_V4.3, PKG_TLS_V1.1, PKG_SSH_V1.0", + "cert_lab": "EWA-Canada" + }, + { + "product": "Senetas CN 9000 Series Ethernet Encryptors v5.5.0", + "vendor": "Senetas", + "level": "EAL 2+ (ALC_FLR.2)", + "cert_lab": "Lightship Security" + }, + { + "product": "Xerox® AltaLink™ C8130/C8135/C8145/C8155/C8170 & B8145/B8155/B8170 with SSD", + "vendor": "Xerox Corporation", + "level": "PP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "RICOH IM C7010, version JE-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "Xerox® AltaLink™ C8130/C8135/C8145/C8155/C8170 & B8145/B8155/B8170 with HDD", + "vendor": "Xerox Corporation", + "level": "PP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "KAYTUS Server Baseboard Management Controller 7.11.00", + "vendor": "KAYTUS Systems Pte Ltd.", + "level": "EAL 2+ (ALC_FLR.2)", + "cert_lab": "EWA-Canada" + }, + { + "product": "Senetas CN 4000/6000 Series Ethernet Encryptors v5.5.0", + "vendor": "Senetas", + "level": "EAL 2+ (ALC_FLR.2)", + "cert_lab": "Lightship Security" + }, + { + "product": "Cisco cEdge Routers running IOS XE 17.12 with SD-WAN 20.12", + "vendor": "Cisco Systems, Inc.", + "level": "EAL 2 + (ALC_FLR.2)", + "cert_lab": "Lightship Security" + }, + { + "product": "Xerox® B410 Printer and C410 Color Printer with Firmware Version 222.030", + "vendor": "Xerox Corporation", + "level": "CPP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "Lexmark MX532, MX632, CX532, and CX635 Multi-Function Printers with Firmware Version 222.030", + "vendor": "Lexmark International, Inc.", + "level": "CPP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "Oracle Identity Governance 12c", + "vendor": "Oracle Corporation", + "level": "PP_ESM_ICM_V2.1", + "cert_lab": "Lightship Security" + }, + { + "product": "Dell Encryption Personal Edition Version 10.10.4", + "vendor": "Dell Inc.", + "level": "PP_APP_V1.4, MOD_FE_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "Lexmark MX532, MX632, CX532 and CX635 Multi-Function Printers with Hard Drive and with Firmware Version 222.030", + "vendor": "Lexmark International, Inc.", + "level": "CPP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "Lexmark MS632 and CS632 Single Function Printers with Firmware Version 222.030", + "vendor": "Lexmark International, Inc.", + "level": "CPP_HCD_V1.0", + "cert_lab": "Lightship Security" + }, + { + "product": "Fortinet FortiManager 7.0", + "vendor": "Fortinet, Inc.", + "level": "EAL 4+ (ALC_FLR.3)", + "cert_lab": "EWA-Canada" + }, + { + "product": "Fortinet FortiAnalyzer 7.0.5", + "vendor": "Fortinet, Inc.", + "level": "EAL 4+ (ALC_FLR.3)", + "cert_lab": "EWA-Canada" + }, + { + "product": "NETSCOUT® Omnis™ Cyber Intelligence with Omnis™ CyberStream v6.3.4", + "vendor": "NETSCOUT", + "level": "CPP_ND_V2.2E", + "cert_lab": "Lightship Security" + }, + { + "product": "NetScaler Version 13.1", + "vendor": "Cloud Software Group", + "level": "CPP_ND_2.2E", + "cert_lab": "Lightship Security" + }, + { + "product": "NETSCOUT nGenius for Flows with nGenius Collector v6.3", + "vendor": "NETSCOUT", + "level": "CPP_ND_V2.2E", + "cert_lab": "Lightship Security" + } + ], + "CERTIFIED": [ + { + "product": "High Sec Labs FA10A-4 and FA10AO-4 Firmware Version 40000-0E7 Peripheral Sharing Devices", + "vendor": "High Sec Labs Ltd.", + "level": "PP_PSD_V4.0, MOD_AO_V1.0", + "certification_date": "2024-07-09" + }, + { + "product": "Belkin Secure KVM models F1DN102KVM-HA-3, F1DN202KVM-HA-3, F1DN104KVM-HA-3, F1DN204KVM-HA-3 Version 33303-C6C6", + "vendor": "Belkin International, Inc.", + "level": "PP_PSS_V3.0", + "certification_date": "2024-06-11" + }, + { + "product": "CipherDriveOne 2.0.1", + "vendor": "KLC Group LLC", + "level": "CPP_FDE_AA_V2.0E", + "certification_date": "2024-06-27" + }, + { + "product": "Dell PowerScale OneFS v9.5", + "vendor": "Dell Technologies", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2024-05-22" + }, + { + "product": "Xerox® AltaLink™ EC8036 and EC8056", + "vendor": "Xerox Corporation", + "level": "PP_HCD_V1.0", + "certification_date": "2024-06-25" + }, + { + "product": "Layer7 API Gateway v10.1.00", + "vendor": "Broadcom Inc.", + "level": "CPP_ND_V2.2E", + "certification_date": "2024-05-24" + }, + { + "product": "Xerox® VersaLink™ C625 and B625 with eMMC", + "vendor": "Xerox Corporation", + "level": "PP_HCD_V1.0", + "certification_date": "2024-05-08" + }, + { + "product": "Xerox® VersaLink™ C625 and B625 with HDD", + "vendor": "Xerox Corporation", + "level": "PP_HCD_V1.0", + "certification_date": "2024-05-14" + }, + { + "product": "Xerox® VersaLink™ C415 and B415 with HDD", + "vendor": "Xerox Corporation", + "level": "PP_HCD_V1.0", + "certification_date": "2024-04-24" + }, + { + "product": "Xerox® VersaLink™ C415 and B415 with eMMC", + "vendor": "Xerox Corporation", + "level": "PP_HCD_V1.0", + "certification_date": "2024-05-03" + }, + { + "product": "High Sec Labs FI11H-M, FI11D-M, FI11PH-M Firmware Version 44404-E7E7 Peripheral Sharing Devices", + "vendor": "High Sec Labs Ltd.", + "level": "PP_PSD_V4.0 with MOD_KM_V1.0, MOD_VI_V1.0", + "certification_date": "2024-04-29" + }, + { + "product": "High Sec Labs SC21H-4, SC82PH-4, SC162PH-4, SMX42D-M, SMX42H-M, SMX42P-M, SMX82D-M, SMX82H-M, SMX82P-M Firmware Version 44404-E7E7 Peripheral Sharing Devices", + "vendor": "High Sec Labs Ltd.", + "level": "PP_PSD_V4.0 with MOD_KM_V1.0, MOD_VI_V1.0", + "certification_date": "2024-04-29" + }, + { + "product": "NETSCOUT® nGeniusONE® with InfiniStreamNG® v6.3.3", + "vendor": "NETSCOUT Systems Inc.", + "level": "CPP_ND_V2.2E", + "certification_date": "2024-04-04" + }, + { + "product": "Adder AS-4CR Multi-Domain Card Reader Firmware Version 40040-0E7", + "vendor": "Adder Technology", + "level": "PP_PSD_V4.0 with MOD_UA_V1.0", + "certification_date": "2024-01-05" + }, + { + "product": "Oracle VM Server for SPARC 3.6 and Oracle Solaris 11.4", + "vendor": "Oracle Corporation", + "level": "PP_BASE_VIRTUALIZATION_v1.1; MOD_SV_V1.1; PKG_SSH_V1.0; PKG_TLS_V1.1", + "certification_date": "2024-01-25" + }, + { + "product": "RICOH IM 370F/460F version JE-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-12-07" + }, + { + "product": "High Sec Labs SK21PH-4, SK41PH-4, DK22PH-4, DK42PH-4, SK81PH-4, DK82PH-4, SX42PH-4, SX82PH-4 Firmware Version 44404-E7E7 Peripheral Sharing Devices", + "vendor": "High Sec Labs Ltd.", + "level": "PP_PSD_V4.0 with MOD_AO_V1.0, MOD_KM_V1.0, MOD_VI_V1.0", + "certification_date": "2023-11-20" + }, + { + "product": "RICOH IM 370 version E-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-12-08" + }, + { + "product": "Dell ECS v3.8.0.3", + "vendor": "Dell Technologies", + "level": "EAL2+ (ALC_FLR.2)", + "certification_date": "2023-11-14" + }, + { + "product": "Dell PowerMax with PowerMaxOS 10 Solutions Enabler 10.0, and Unisphere for PowerMax 10.0", + "vendor": "Dell Technologies", + "level": "EAL2+ (ALC_FLR.2)", + "certification_date": "2023-10-20" + }, + { + "product": "BAE Systems STOP™ 8.8.2", + "vendor": "BAE Systems", + "level": "PP_OS_V4.2.1", + "certification_date": "2023-09-15" + }, + { + "product": "RICOH IM 2500/3000/3500/4000/5000/6000 version JE-1.10-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-09-08" + }, + { + "product": "RICOH IM 7000/8000/9000/9000T version JE-1.10-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-09-08" + }, + { + "product": "Oracle Access Management 12c", + "vendor": "Oracle Corporation", + "level": "PP_ESM_PM_V2.1, PP_ESM_AC_V2.1", + "certification_date": "2023-09-20" + }, + { + "product": "RICOH IM C530F / C530FB version E-1.10-H", + "vendor": "Ricoh Company, Ltd", + "level": "PP_HCD_V1.0", + "certification_date": "2023-08-29" + }, + { + "product": "RICOH Pro C5300S/C5310S Enhanced Security Firmware version E-1.00-H", + "vendor": "Ricoh Company, Ltd", + "level": "PP_HCD_V1.0", + "certification_date": "2023-07-28" + }, + { + "product": "Lexmark CX730, CX930, CX931 and MX931 Multi-Function Printers with Trusted Platform Module and Hard Drive and without Fax and with Firmware Version 081.234", + "vendor": "Lexmark International, Inc.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-06-23" + }, + { + "product": "Lexmark MX521, MX931, CX730, CX930, and CX931 Multi-Function Printers with Trusted Platform Module, without Fax and Hard Drive and with Firmware Version 081.234", + "vendor": "Lexmark International, Inc.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-06-23" + }, + { + "product": "Lexmark MX421, MX432, MX521, MX622, MX721, MX722, MX725, MX931, CX622, CX625, CX730, CX735, CX930, CX931, CX942, CX943 and CX944 Multi-Function Printers with Trusted Platform Module and Fax and without Hard Drive and with Firmware Version 081.234", + "vendor": "Lexmark International, Inc.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-06-22" + }, + { + "product": "Lexmark MS622, MS822, MS826, CS622, CS730, CS735, CS820, and CS943 Single Function Printers with Trusted Platform Module and Firmware Version 081.234", + "vendor": "Lexmark International, Inc.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-06-23" + }, + { + "product": "RICOH IM C2010/C2510/C2519/C3010/C3510/C3519/C4510/C5510/C6010 version JE-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-06-29" + }, + { + "product": "Lexmark MX432, MX522, MX622, MX721, MX722, MX822, MX826, MX931, CX622, CX625, CX730, CX735, CX820, CX825, CX860, CX930, CX931, CX942, CX943, and CX944 MFPs with TPM, Fax and Hard Drive with firmware version 081.234", + "vendor": "Lexmark International, Inc.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-05-24" + }, + { + "product": "RICOH IM C6500/C8000 Enhanced Security Firmware version E-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-04-27" + }, + { + "product": "RICOH IM 2500/3000/3500/4000/5000/6000 Enhanced Security Firmware version E-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-05-01" + }, + { + "product": "RICOH IM 7000/8000/9000 Enhanced Security Firmware version E-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-05-01" + }, + { + "product": "RICOH IM C300/C300F/C300FLT/C400F/C400SRF/C400FLT Enhanced Security Firmware version E-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-04-27" + }, + { + "product": "RICOH IM 550/600/600SR Enhanced Security Firmware version E-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-04-27" + }, + { + "product": "RICOH IM C2000 / C2000LT / C2500 / C2500LT / C3000 / C3000LT / C3500 / C3500LT / C4500 /C4500LT / C5500 / C5500LT/ C6000 / C6000LT Enhanced Security Firmware version E-1.00-H", + "vendor": "Ricoh Company Ltd.", + "level": "PP_HCD_V1.0", + "certification_date": "2023-04-27" + }, + { + "product": "Oracle Linux 8.4", + "vendor": "Oracle Corporation", + "level": "PP_OS_V4.2.1, PKG_SSH_V1.0", + "certification_date": "2023-04-12" + }, + { + "product": "TestStream Management Software v5.3.0 on nGenius 3900 Series Switches", + "vendor": "NetScout Systems, Inc.", + "level": "CPP_ND_V2.2E", + "certification_date": "2023-04-17" + }, + { + "product": "Cisco Catalyst 9800 Series Wireless Controllers and Access Points 17.6", + "vendor": "Cisco Systems, Inc.", + "level": "CPP_ND_V2.2E, PP_WLAN_AS_EP_V1.0", + "certification_date": "2023-03-20" + }, + { + "product": "Oracle Linux 7.6 UEK 5 KVM & Virtualization Manager 4.3", + "vendor": "Oracle Corporation", + "level": "PP_BASE_VIRTUALIZATION_V1.0, EP_SV_V1.0, PP_SSH_EP_V1.0", + "certification_date": "2023-03-03" + }, + { + "product": "High Sec Labs SK41PHU-4, DK42PHU-4, SX42PHU-4, SX82PHU-4, SC42DHU-4, SC42PHU-4 Firmware Version 44444-E7E7 Peripheral Sharing Devices", + "vendor": "High Sec Labs Ltd.", + "level": "PP_PSD_V4.0 with MOD_AO_V1.0, MOD_KM_V1.0, MOD_UA_V1.0, MOD_VI_V1.0", + "certification_date": "2022-12-20" + }, + { + "product": "Adder AVS-4228, AVS-42216, XDS441, XDS441FX Firmware Version 44404-E7E7 Peripheral Sharing Devices\n\t\t\tAdder AVS-4228, AVS-42216 Firmware Version 44404-E7E7 Peripheral Sharing Devices (August 2023)", + "vendor": "Adder Technology", + "level": "PP_PSD_V4.0 with MOD_KM_V1.0, MOD_VI_V1.0", + "certification_date": "2022-12-07" + }, + { + "product": "SentinelOne Singularity Complete Version S", + "vendor": "SentinelOne, Inc.", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2022-12-19" + }, + { + "product": "Dell EMC Unity OE v5.2", + "vendor": "Dell EMC", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2022-12-13" + }, + { + "product": "FortiAnalyzer 6.2.8", + "vendor": "Fortinet, Inc.", + "level": "CPP_ND_V2.2E", + "certification_date": "2022-12-12" + }, + { + "product": "RICOH IM C300/C300F/C400F/C400SRF version JE-1.10-H", + "vendor": "Ricoh Company, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2022-11-23" + }, + { + "product": "RICOH IM 550/600/600SR version E-1.10-H", + "vendor": "Ricoh Company, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2022-11-23" + }, + { + "product": "RICOH IM C5300S/C5310S version JE-1.10-H", + "vendor": "Ricoh Company, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2022-11-14" + }, + { + "product": "RICOH IM C6500/C8000 version JE-1.10-H", + "vendor": "Ricoh Company, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2022-11-14" + }, + { + "product": "Fortinet FortiManager 6.2.8", + "vendor": "Fortinet, Inc.", + "level": "CPP_ND_V2.2E", + "certification_date": "2022-11-07" + }, + { + "product": "Cisco 900 Series Integrated Services Routers running IOS v15.9", + "vendor": "Cisco Systems, Inc.", + "level": "CPP_ND_V2.2E with MOD_VPNGW_v1.1", + "certification_date": "2022-11-02" + }, + { + "product": "RICOH IM C2000/C2000LT/C2500/C2500LT/C3000/C3000LT/C3500/C3500LT/ C4500/C4500LT/C5500/C5500LT/C6000/C6000LT version JE-1.20-H", + "vendor": "Ricoh Company, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2022-09-28" + }, + { + "product": "Dell EMC™ Data Domain® v7.2", + "vendor": "Dell EMC™", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2022-09-26" + }, + { + "product": "Citrix Hypervisor® 8.2 LTSR Premium Edition (CU1)", + "vendor": "Citrix Systems, Inc.", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2022-08-23" + }, + { + "product": "McAfee Endpoint Security 10.7.x with ePolicy Orchestrator 5.10.x", + "vendor": "Trellix", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2022-07-28" + }, + { + "product": "NetApp StorageGRID 11.5", + "vendor": "NetApp Inc.", + "level": "EAL 2+ (ALC_FLR.1)", + "certification_date": "2022-07-15" + }, + { + "product": "AhnLab CPP 1.0", + "vendor": "AhnLab, Inc.", + "level": "EAL 2+ (ALC_FLR.1)", + "certification_date": "2022-07-14" + }, + { + "product": "nGenius 5000 and 7000 Series Packet Flow Switches with PFOS 6.0.6", + "vendor": "NETSCOUT Systems, Inc.", + "level": "CPP_ND_V2.2E", + "certification_date": "2022-06-07" + }, + { + "product": "Trend Micro Deep Security 20", + "vendor": "Trend Micro Inc.", + "level": "EAL 2+ (ALC_FLR.1)", + "certification_date": "2022-05-31" + }, + { + "product": "Adder AVS-4112, AVS-2112, AVS-4114, AVS-4214, AVS-2114, AVS-2214, AVS-4128, AVS-4124, AVS-1124, AVS-4224 Firmware Version 44404-E7E7, Peripheral Sharing Devices", + "vendor": "Adder Technology", + "level": "PP_PSD_v4.0, MOD_AO_v1.0, MOD_KM_v1.0, MOD_VI_v1.0", + "certification_date": "2022-04-20" + }, + { + "product": "Keysight Technologies Vision Series Network Packet Broker v5.7.1\n\t\t\tKeysight Technologies Vision Series Network Packet Broker v5.10.0 (January 2024)", + "vendor": "Keysight Technologies", + "level": "CPP_ND_v2.2E", + "certification_date": "2022-03-04" + }, + { + "product": "Belkin F1DN102MOD-xx-4, F1DN202MOD-xx-4, F1DN104MOD-xx-4, F1DN204MOD-xx-4, F1DN108MOD-xx-4, F1DN208MOD-xx-4 Firmware Version 44404-E7E7 Peripheral Sharing Devices", + "vendor": "Belkin International, Inc.", + "level": "PP_PSD_v4.0, MOD_KM_v1.0, MOD_VI_v1.0", + "certification_date": "2021-07-11" + }, + { + "product": "Belkin F1DN002MOD-KM-4, F1DN004MOD-KM-4 and F1DN-FLTR-HID-4 Firmware Version 40404-0E7 Peripheral Sharing Devices", + "vendor": "Belkin International, Inc.", + "level": "PP_PSD_v4.0, MOD_KM_v1.0", + "certification_date": "2022-01-24" + }, + { + "product": "Cisco Web Security Appliance with AsyncOS 11.8", + "vendor": "Cisco Systems, Inc.", + "level": "CPP_ND_v2.2E", + "certification_date": "2022-02-28" + }, + { + "product": "FortiGate/FortiOS Version 6.2.7", + "vendor": "Fortinet, Inc.", + "level": "CPP_ND_V2.2E w/ MOD_CPP_FW_v1.4e, MOD_VPNGW_v1.1,MOD_IPS_V1.0", + "certification_date": "2022-01-14" + }, + { + "product": "Fortinet FortiGate™ Next Generation Firewalls with FortiOS 6.2.7", + "vendor": "Fortinet, Incorporated", + "level": "EAL 4+ (ALC_FLR.3)", + "certification_date": "2021-10-15" + }, + { + "product": "NetApp Element Software 12.2 on SolidFire Appliances", + "vendor": "NetApp, Inc.", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2022-03-08" + }, + { + "product": "Sphyrna Security Unidirectional Gateway - Data Diode Identifier: 2010-UG100-SSI", + "vendor": "Sphyrna Security Incorporated", + "level": "EAL4+ (ADV_INT.2, ALC_CMC.5, ALC_CMS.5, ALC_DVS.2, ALC_FLR.3, ATE_DPT.2 and AVA_VAN.4)", + "certification_date": "2021-09-07" + }, + { + "product": "NetApp E-Series & EF-Series with SANtricity OS 11.70", + "vendor": "NetApp, Inc.", + "level": "NDcPP v2.2e", + "certification_date": "2021-09-21" + }, + { + "product": "Blackline Systems Corporation BSC-CDS Unidirectional Subsystem PN: 710-0185-00", + "vendor": "Blackline Systems Corporation", + "level": "EAL 4+ (ADV_INT.2, ALC_CMC.5, ALC_CMS.5, ALC_DVS.2, ALC_FLR.3, ATE_DPT.2 and AVA_VAN.4)", + "certification_date": "2021-09-15" + }, + { + "product": "RICOH IM C530F/C530FB version E-1.00-H", + "vendor": "RICOH Company, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2021-10-13" + }, + { + "product": "RICOH IM 2500/3000/3500/4000/5000/6000 version JE-1.00-H", + "vendor": "RICOH Company, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2021-10-18" + }, + { + "product": "RICOH IM 7000/8000/9000/9000T version JE-1.00-H", + "vendor": "RICOH Company, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2021-10-18" + }, + { + "product": "Cisco Email Security Appliance with AsyncOS 13.0", + "vendor": "Cisco Systems, Inc", + "level": "cPP_ND_v2.1", + "certification_date": "2021-09-20" + }, + { + "product": "Belkin F1DN104KVM-UNN4, F1DN204KVM-UNN4, F1DN102KVM-UNN4, F1DN202KVM-UNN4 Firmware Version 44404-E7E7 Peripheral Sharing Devices\n\t\t\tBelkin F1DN104KVM-UNN4, F1DN204KVM-UNN4, F1DN102KVM-UNN4, F1DN202KVM-UNN4, F1DN104KVM-HA-4, F1DN204KVM-HA-4, F1DN102KVM-HA-4, F1DN202KVM-HA-4 Firmware Version 44404-E7E7 Peripheral Sharing Devices (April 2023)", + "vendor": "Belkin International, Inc.", + "level": "PP_PSD_v4.0, MOD_AO_V1.0, MOD_KM_V1.0, MOD_VI_V1.0", + "certification_date": "2021-07-08" + }, + { + "product": "Belkin F1DN104KVM-UN-4, F1DN204KVM-UN-4, F1DN102KVM-UN-4, F1DN202KVM-UN-4, F1DN108KVM-UN-4, F1DN208KVM-UN-4, F1DN116KVM-UN-4 Firmware Version 44444-E7E7 Peripheral Sharing Devices", + "vendor": "Belkin International, Inc.", + "level": "PP_PSD_V4.0, MOD_AO_V1.0, MOD_KM_V1.0, MOD_UA_V1.0, MOD_VI_V1.0", + "certification_date": "2021-04-29" + }, + { + "product": "Oracle Linux 7.6", + "vendor": "Oracle Corporation", + "level": "PP_OS_V4.2.1 PP_SSH_EP_v1.0", + "certification_date": "2021-07-19" + }, + { + "product": "Crunchy Certified PostgreSQL 12.5", + "vendor": "Crunchy Data Solutions, Inc.", + "level": "DBMS PP Base Package, V2.12", + "certification_date": "2021-03-16" + }, + { + "product": "OPSWAT MetaDefender Core v4.19.0 & MetaDefender Kiosk v4.4.5", + "vendor": "OPSWAT, Inc.", + "level": "EAL 2+ (ALC_FLR.1)", + "certification_date": "2021-03-03" + }, + { + "product": "CipherDrive v1.2.2\n\t\t\tCipherDrive v1.2.3 (January 2023)", + "vendor": "KLC Group LLC", + "level": "CPP_FDE_AA_V2.0E", + "certification_date": "2021-02-17" + }, + { + "product": "Oracle Solaris 11.4", + "vendor": "Oracle Corporation", + "level": "PP_OS_v4.2.1, PP_SSH_EP_v1.0", + "certification_date": "2021-02-08" + }, + { + "product": "Lexmark MS622, MS822, MS826, CS622, CS720, CS725, CS820, CS921 and CS923 w/firmware 073.239 and Lexmark Secure Element (P/N 57X0185)", + "vendor": "Lexmark International, Inc.", + "level": "PP_HCD_V1.0", + "certification_date": "2021-02-03" + }, + { + "product": "Lexmark MX421, MX521, MX622, MX721, MX722, MX725, CX622, CX625, CX725 w/firmware 073.239 and Lexmark Secure Element (P/N 57X0185)", + "vendor": "Lexmark International, Inc.", + "level": "PP_HCD_V1.0", + "certification_date": "2021-01-26" + }, + { + "product": "Lexmark MX522, MX622h, MX721h, MX722h, MX822, MX826, CX622h, CX625h, CX725h, CX820, CX825, CX860, CX920, CX921, CX922, CX923, CX924, M C550SRF, M C550FG w/firmware 073.239 and Lexmark Secure Element (P/N 57X0185)", + "vendor": "Lexmark International, Inc.", + "level": "PP_HCD_V1.0", + "certification_date": "2021-01-14" + }, + { + "product": "Fortinet FortiGate/FortiOS 6.0.9", + "vendor": "Fortinet Inc.", + "level": "CPP_FW_V2.0E w/EP_IPS_V2.11, EP_VPN_GW_V2.1", + "certification_date": "2021-01-05" + }, + { + "product": "RICOH PRO C5300S/C5310S, version JE-1.00-H", + "vendor": "RICOH COMPANY, LTD", + "level": "PP_HCD_V1.0", + "certification_date": "2020-12-21" + }, + { + "product": "RICOH IM C6500/C8000, version JE-1.00-H", + "vendor": "RICOH COMPANY, LTD", + "level": "PP_HCD_V1.0", + "certification_date": "2020-12-17" + }, + { + "product": "RICOH IM 550/600/600SR, version E-1.00-H", + "vendor": "RICOH COMPANY, LTD", + "level": "PP_HCD_V1.0", + "certification_date": "2020-12-17" + }, + { + "product": "RICOH IM C300/C300F/C400F/C400SRF, version JE-1.00-H", + "vendor": "RICOH COMPANY, LTD", + "level": "PP_HCD_V1.0", + "certification_date": "2020-12-16" + }, + { + "product": "Citrix Virtual Apps and Desktops 7 1912 LTSR Premium Edition\n\n\t\t\tCitrix Virtual Apps and Desktops 7 2203 LTSR Premium Edition (CVAD) (May 2022)", + "vendor": "Citrix Systems, Inc.", + "level": "EAL 2 + (ALC_FLR.2)", + "certification_date": "2020-10-26" + }, + { + "product": "Samsung 5G gNB AU, DU v19.A", + "vendor": "Samsung Electronics Co. Ltd.", + "level": "CPP_ND_V2.2E", + "certification_date": "2020-11-10" + }, + { + "product": "McAfee Change Control and Application Control 8.3.0 with ePolicy Orchestrator 5.10.0", + "vendor": "McAfee, LLC.", + "level": "EAL2 + (ALC_FLR.2)", + "certification_date": "2020-10-16" + }, + { + "product": "Vormetric Data Security Manager V6000, Version 6.3", + "vendor": "Thales DIS CPL USA, Inc.", + "level": "PP_ESM_PM_V2.1", + "certification_date": "2020-10-07" + }, + { + "product": "Tripwire Enterprise Version 8.8.2.2\n\t\t\tTripwire Enterprise Version 8.9.1 (August 2022)", + "vendor": "Tripwire, Inc.", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2020-09-03" + }, + { + "product": "Dell EMC XtremIO v6.3.1-5 with the 6.3.1-5 Storage Controller Software", + "vendor": "Dell EMC", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2020-10-14" + }, + { + "product": "Netscout nGeniusPULSE Server v3.2", + "vendor": "NETSCOUT Systems, Inc", + "level": "CPP_ND_V2.1", + "certification_date": "2020-10-05" + }, + { + "product": "Dell EMC™ VxFlex 3.0.1.208 with VxFlex Ready Node 14G Hardware", + "vendor": "Dell EMC", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2020-09-09" + }, + { + "product": "Dell EMC Networking SmartFabric OS10 v10.5.1", + "vendor": "Dell EMC", + "level": "CPP_ND_V2.1", + "certification_date": "2020-09-15" + }, + { + "product": "Dell EMC™ SupportAssist Enterprise 4.0 with Policy Manager 6.8", + "vendor": "Dell EMC", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2020-08-06" + }, + { + "product": "Ixia, A Keysight Business Vision Series Network Packet Broker v5.3.0", + "vendor": "Ixia, A Keysight Business", + "level": "CPP_ND_V2.1", + "certification_date": "2020-07-22" + }, + { + "product": "Fortinet FortiGate 6000 Series w/ FortiOS 5.6", + "vendor": "Fortinet, Inc.", + "level": "CPP_FW_V2.0e; EP_VPN_GW_V2.1; EP_IPS_V2.11", + "certification_date": "2020-07-29" + }, + { + "product": "Dell EMC™ VxRail™ 4.7", + "vendor": "Dell EMC", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2020-06-30" + }, + { + "product": "Market Central SecureSwitch® Fiber Optic Switch Models: A, B, C, D, 1:1, 2:1, 3:1, 4:1, 5:1, 6:1, 7:1 and 8:1\n\t\t\tMarket Central SecureSwitch® Fiber Optic Switch Models: A, B, C, D, 1:1, 2:1, 3:1, 4:1, 5:1, 6:1, 7:1 and 8:1 (March 2022)", + "vendor": "Market Central, Inc.", + "level": "EAL 4+ (ALC_FLR.1)", + "certification_date": "2020-06-25" + }, + { + "product": "Aruba Mobility Master with ArubaOS 8.2", + "vendor": "Aruba, a Hewlett Packard Enterprise company", + "level": "CPP_ND_v2.1", + "certification_date": "2020-07-10" + }, + { + "product": "Symantec Privileged Access Manager v3.3.0.1085", + "vendor": "Broadcom", + "level": "PP_ESM_PM_V2.1", + "certification_date": "2020-05-31" + }, + { + "product": "Veritas NetBackup™ 8.2 and NetBackup 5240 Appliance Release 3.2", + "vendor": "Veritas Technologies", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2020-02-28" + }, + { + "product": "Dell EMC™ Isilon with OneFS v8.2.0.0", + "vendor": "Dell EMC", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2020-01-31" + }, + { + "product": "Dell MX7000 Modular Chassis with Management Module v1.00.10", + "vendor": "Dell Technologies", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2020-01-07" + }, + { + "product": "RICOH IM C2000 / C2500 / C3000 / C3500 / C4500 / C5500 / C6000 v.JE-1.00-H", + "vendor": "RICOH COMPANY, LTD.", + "level": "PP_HCD_V1.0", + "certification_date": "2020-01-06" + }, + { + "product": "Arista Networks Switches EOS 4.22.1FX-CC", + "vendor": "Arista Networks, Inc.", + "level": "CPP_ND_V2.1", + "certification_date": "2019-12-03" + }, + { + "product": "Integrated Dell Remote Access Controller 9", + "vendor": "Dell Technologies", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2019-11-13" + }, + { + "product": "AhnLab MDS, MDS with MTA, and MDS Manager v2.1", + "vendor": "AhnLab, Inc.", + "level": "CPP_ND_V2.1", + "certification_date": "2019-10-29" + }, + { + "product": "Dell EMC™ Avamar® v18.1", + "vendor": "Dell EMC™", + "level": "EAL 2+ (ALC_FLR.2)", + "certification_date": "2019-10-09" + }, + { + "product": "AhnLab EPP, EDR 1.0 and V3 Endpoint Security 9.0", + "vendor": "AhnLab", + "level": "EAL 2+ (ALC_FLR.1)", + "certification_date": "2019-08-27" + }, + { + "product": "Fortinet FortiProxy v1.0", + "vendor": "Fortinet, Inc.", + "level": "CPP_ND_V2.0E", + "certification_date": "2019-08-08" + }, + { + "product": "NETSCOUT Sightline and Threat Mitigation System v9.7", + "vendor": "NETSCOUT Systems Inc.", + "level": "CPP_ND_V2.2E", + "certification_date": "2024-05-14" + } + ] + } + } + } +} \ No newline at end of file -- cgit v1.3.1 From 9eaa9c27a0130ee99c0e715730b9cd07b0bb9c83 Mon Sep 17 00:00:00 2001 From: J08nY Date: Fri, 19 Jul 2024 18:50:57 +0200 Subject: Fix USA scheme download. --- src/sec_certs/constants.py | 7 +- src/sec_certs/sample/cc_scheme.py | 213 ++++++++------------- tests/cc/test_cc_schemes.py | 1 - .../dataset/auxiliary_datasets/scheme_dataset.json | 2 +- 4 files changed, 89 insertions(+), 134 deletions(-) diff --git a/src/sec_certs/constants.py b/src/sec_certs/constants.py index e9b6d882..69f0c6cd 100644 --- a/src/sec_certs/constants.py +++ b/src/sec_certs/constants.py @@ -145,7 +145,6 @@ CC_SWEDEN_INEVAL_URL = CC_SWEDEN_BASE_URL + "/verksamhet/ovrig-verksamhet/csec/p CC_SWEDEN_ARCHIVED_URL = CC_SWEDEN_BASE_URL + "/verksamhet/ovrig-verksamhet/csec/arkiverade-certifikat-aldre-an-5-ar/" CC_TURKEY_ARCHIVED_URL = "https://statik.tse.org.tr/upload/tr/dosya/icerikyonetimi/3300/03112021143434-2.pdf" CC_USA_BASE_URL = "https://www.niap-ccevs.org" -CC_USA_PRODUCT_URL = CC_USA_BASE_URL + "/Product/" -CC_USA_CERTIFIED_URL = CC_USA_BASE_URL + "/Product/PCL.cfm" -CC_USA_INEVAL_URL = CC_USA_BASE_URL + "/Product/PINE.cfm" -CC_USA_ARCHIVED_URL = CC_USA_BASE_URL + "/Product/Archived.cfm" +CC_USA_PRODUCTS_URL = CC_USA_BASE_URL + "/api/project/product/pcl_products/" +CC_USA_FILES_URL = CC_USA_BASE_URL + "/api/file/get_pcl_files/" +CC_USA_GETFILE_URL = CC_USA_BASE_URL + "/api/file/get_public_file/" diff --git a/src/sec_certs/sample/cc_scheme.py b/src/sec_certs/sample/cc_scheme.py index 7fb9e18e..51dfd0f8 100644 --- a/src/sec_certs/sample/cc_scheme.py +++ b/src/sec_certs/sample/cc_scheme.py @@ -65,12 +65,13 @@ __all__ = [ ] -def _get(url: str, session, **kwargs) -> Response: +def _getq(url: str, params, session=None, **kwargs) -> Response: with warnings.catch_warnings(): warnings.simplefilter("ignore", category=InsecureRequestWarning) conn = session if session else requests resp = conn.get( url, + params=params, headers={"User-Agent": "sec-certs.org"}, verify=False, **kwargs, @@ -80,6 +81,10 @@ def _get(url: str, session, **kwargs) -> Response: return resp +def _get(url: str, session=None, **kwargs) -> Response: + return _getq(url, None, session, **kwargs) + + def _get_page(url: str, session=None) -> BeautifulSoup: return BeautifulSoup(_get(url, session).content, "html5lib") @@ -1444,6 +1449,78 @@ def get_turkey_certified() -> list[dict[str, Any]]: return results +def _get_usa(args, enhanced: bool, artifacts: bool): # noqa: C901 + # TODO: There is more information in the API (like about PPs, etc.) + def map_cert(cert, files=None): # noqa: C901 + result = { + "product": cert["product_name"], + "id": f"CCEVS-VR-VID{cert['product_id']}", + "url": constants.CC_USA_BASE_URL + f"/product/{cert['product_id']}", + "certification_date": cert["certification_date"], + "expiration_date": cert["sunset_date"], + "category": cert["tech_type"], + "vendor": cert["vendor_id_name"], + "evaluation_facility": cert["assigned_lab_name"], + "scheme": cert["submitting_country_id_code"], + } + if files: + for file in files["eval_files"]: + if file["file_label"] == "Validation Report": + dt = datetime.fromisoformat(file["uploaded_on"]) + result["id"] += f"-{dt.year}" + result["report_link"] = constants.CC_USA_GETFILE_URL + f"?file_id={file['file_id']}" + if artifacts: + result["report_hash"] = _get_hash(result["report_link"]).hex() + elif file["file_label"] == "CC Certificate": + result["cert_link"] = constants.CC_USA_GETFILE_URL + f"?file_id={file['file_id']}" + if artifacts: + result["cert_hash"] = _get_hash(result["cert_link"]).hex() + elif file["file_label"] == "Security Target": + result["target_link"] = constants.CC_USA_GETFILE_URL + f"?file_id={file['file_id']}" + if artifacts: + result["target_hash"] = _get_hash(result["target_link"]).hex() + elif file["file_label"] == "Assurance Activity Report (AAR)": + result["aar_link"] = constants.CC_USA_GETFILE_URL + f"?file_id={file['file_id']}" + if artifacts: + result["aar_hash"] = _get_hash(result["aar_link"]).hex() + elif file["file_label"] == "Administrative Guide (AGD)": + result["agd_link"] = constants.CC_USA_GETFILE_URL + f"?file_id={file['file_id']}" + if artifacts: + result["agd_hash"] = _get_hash(result["agd_link"]).hex() + + return result + + session = requests.session() + results = [] + offset = 0 + got = 0 + while True: + resp = _getq( + constants.CC_USA_PRODUCTS_URL, + {"limit": 100, "offset": offset, **args}, + session, + ) + json = resp.json() + count = json["count"] + for cert in json["results"]["products"]: + got += 1 + if "from_cc_portal" in cert: + continue + files = None + if enhanced: + resp = _getq( + constants.CC_USA_FILES_URL, + {"product_id": cert["product_id"]}, + session, + ) + files = resp.json() + results.append(map_cert(cert, files)) + offset += 100 + if got >= count: + break + return results + + def get_usa_certified( # noqa: C901 enhanced: bool = True, artifacts: bool = False ) -> list[dict[str, Any]]: @@ -1454,83 +1531,11 @@ def get_usa_certified( # noqa: C901 :param artifacts: Whether to download and compute artifact hashes (way slower, even more data). :return: The entries. """ - # TODO: Information could be expanded by following the cc_claims (has links to protection profiles). - soup = _get_page(constants.CC_USA_CERTIFIED_URL) - tbody = soup.find("table", class_="tablesorter").find("tbody") - results = [] - for tr in tbody.find_all("tr"): - tds = tr.find_all("td") - vendor_span = tds[0].find("span", class_="b u") - product_link = tds[0].find("a") - scheme_img = tds[6].find("img") - # Only return the US certifications. - if scheme_img["title"] != "USA": - continue - cert: dict[str, Any] = { - "product": sns(product_link.text), - "vendor": sns(vendor_span.text), - "product_link": urljoin(constants.CC_USA_PRODUCT_URL, product_link["href"]), - "id": sns(tds[1].text), - "cc_claim": sns(tds[2].text), - "cert_lab": sns(tds[3].text), - "certification_date": sns(tds[4].text), - "assurance_maintenance_date": sns(tds[5].text), - } - if enhanced: - e: dict[str, Any] = {} - if not cert["product_link"]: - continue - cert_page = _get_page(cert["product_link"]) - details = cert_page.find("div", class_="txt2 lma") - for span in details.find_all("span"): - title = sns(span.text) - if not title: - continue - sibling = span.next_sibling - value = sns(sibling.text) - if "Certificate Date" in title: - e["certification_date"] = value - elif "Product Type" in title: - e["product_type"] = value - elif "Conformance Claim" in title: - e["cc_claim"] = value - elif "Validation Report Number" in title: - e["cert_id"] = value - elif "PP Identifier" in title: - e["protection_profile"] = sns(span.find_next_sibling("a").text) - elif "CC Testing Lab" in title: - e["evaluation_facility"] = sns(span.find_next_sibling("a").text) - links = cert_page.find_all("a", class_="pseudobtn1") - for link in links: - name = sns(link.text) - href = urljoin(constants.CC_USA_BASE_URL, sns(link["href"])) - if not name: - continue - if "CC Certificate" in name: - e["cert_link"] = href - if artifacts: - e["cert_hash"] = _get_hash(href).hex() - elif "Security Target" in name: - e["target_link"] = href - if artifacts: - e["target_hash"] = _get_hash(href).hex() - elif "Validation Report" in name: - e["report_link"] = href - if artifacts: - e["report_hash"] = _get_hash(href).hex() - elif "Assurance Activity" in name: - e["assurance_activity_link"] = href - if artifacts: - e["assurance_activity_hash"] = _get_hash(href).hex() - elif "Administrative Guide" in name: - guides = e.setdefault("administrative_guides", []) - guide = {"link": href} - guides.append(guide) - if artifacts: - guide["hash"] = _get_hash(href).hex() - cert["enhanced"] = e - results.append(cert) - return results + return _get_usa( + {"certification_status": "Certified", "publish_status": "Published"}, + enhanced, + artifacts, + ) def get_usa_in_evaluation() -> list[dict[str, Any]]: @@ -1539,29 +1544,7 @@ def get_usa_in_evaluation() -> list[dict[str, Any]]: :return: The entries. """ - # TODO: Information could be expanded by following the cc_claims (has links to protection profiles). - soup = _get_page(constants.CC_USA_INEVAL_URL) - tbody = soup.find("table", class_="tablesorter").find("tbody") - results = [] - for tr in tbody.find_all("tr"): - tds = tr.find_all("td") - vendor_span = tds[0].find("span", class_="b u") - product_name = None - for child in tds[0].children: - if isinstance(child, NavigableString): - product_name = sns(child) - break - cert = { - "vendor": sns(vendor_span.text), - "id": sns(tds[1].text), - "cc_claim": sns(tds[2].text), - "cert_lab": sns(tds[3].text), - "kickoff_date": sns(tds[4].text), - } - if product_name: - cert["product"] = product_name - results.append(cert) - return results + return _get_usa({"status": "In Progress", "publish_status": "Published"}, False, False) def get_usa_archived() -> list[dict[str, Any]]: @@ -1570,33 +1553,7 @@ def get_usa_archived() -> list[dict[str, Any]]: :return: The entries. """ - # TODO: Information could be expanded by following the cc_claims (has links to protection profiles). - soup = _get_page(constants.CC_USA_ARCHIVED_URL) - tbody = soup.find("table", class_="tablesorter").find("tbody") - results = [] - for tr in tbody.find_all("tr"): - tds = tr.find_all("td") - scheme_img = tds[5].find("img") - # Only return the US certifications. - if scheme_img["title"] != "USA": - continue - vendor_span = tds[0].find("span", class_="b u") - product_name = None - for child in tds[0].children: - if isinstance(child, NavigableString): - product_name = sns(child) - break - cert = { - "vendor": sns(vendor_span.text), - "id": sns(tds[1].text), - "cc_claim": sns(tds[2].text), - "cert_lab": sns(tds[3].text), - "certification_date": sns(tds[4].text), - } - if product_name: - cert["product"] = product_name - results.append(cert) - return results + return _get_usa({"status": "Archived", "publish_status": "Published"}, False, False) class EntryType(Enum): diff --git a/tests/cc/test_cc_schemes.py b/tests/cc/test_cc_schemes.py index 9e1e927f..1740cb27 100644 --- a/tests/cc/test_cc_schemes.py +++ b/tests/cc/test_cc_schemes.py @@ -178,7 +178,6 @@ def test_turkey(): @pytest.mark.xfail(reason="May fail due to server errors.", raises=RequestException) def test_usa(): - pytest.skip() certified = CCSchemes.get_usa_certified() assert len(certified) != 0 assert absolute_urls(certified) diff --git a/tests/data/cc/dataset/auxiliary_datasets/scheme_dataset.json b/tests/data/cc/dataset/auxiliary_datasets/scheme_dataset.json index 64db2e84..3b7348d8 100644 --- a/tests/data/cc/dataset/auxiliary_datasets/scheme_dataset.json +++ b/tests/data/cc/dataset/auxiliary_datasets/scheme_dataset.json @@ -4,7 +4,7 @@ "CA": { "_type": "sec_certs.sample.cc_scheme.CCScheme", "country": "CA", - "timestamp": "2024-07-19T17:14:26.369494", + "timestamp": "2024-07-19T17:15:33.014552", "lists": { "INEVALUATION": [ { -- cgit v1.3.1 From ee63131f13f3900083f41e0731d1a477546410c2 Mon Sep 17 00:00:00 2001 From: J08nY Date: Sun, 21 Jul 2024 14:40:53 +0200 Subject: Fix USA scheme parsing on Python < 3.11. Datetime.fromisoformat changed behavior then. --- src/sec_certs/sample/cc_scheme.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/sec_certs/sample/cc_scheme.py b/src/sec_certs/sample/cc_scheme.py index 51dfd0f8..2785551d 100644 --- a/src/sec_certs/sample/cc_scheme.py +++ b/src/sec_certs/sample/cc_scheme.py @@ -18,6 +18,7 @@ from urllib.parse import urljoin import requests import tabula from bs4 import BeautifulSoup, NavigableString, Tag +from dateutil.parser import isoparse from requests import Response from urllib3.connectionpool import InsecureRequestWarning @@ -1466,7 +1467,7 @@ def _get_usa(args, enhanced: bool, artifacts: bool): # noqa: C901 if files: for file in files["eval_files"]: if file["file_label"] == "Validation Report": - dt = datetime.fromisoformat(file["uploaded_on"]) + dt = isoparse(file["uploaded_on"]) result["id"] += f"-{dt.year}" result["report_link"] = constants.CC_USA_GETFILE_URL + f"?file_id={file['file_id']}" if artifacts: -- cgit v1.3.1