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